What's up, everyone? So who among you has ever released a gem? OK, good. I like it. OK, who has released a popular-ass gem? Like, tons of contributors, tons of users, tons of love. OK, all right. So we want to get from group one and not group one, everyone into group two. OK, so that's what we're going to do today. Before I get started, quick intro. My name is Matt. What's going on? If you want to tweet insults, that's a zero. I live in Brooklyn. Looks like this. I work for Genius. We're a platform for annotations. One time, John Resig used our platform. It was really cool. And here's my talk. So we're going to talk about seven specific things that are going to make your gem more appealing. It's going to make your users happy, right? So your gem should make users happy, of course. This is a Ruby conference. So we're going to talk about, first, how to get users up and running quickly. We'll talk about how to write really good documentation. We'll talk about how to change your gem without causing your applications pain. We'll talk about how to coexist with your user's applications environment in a nice way. We'll talk about how abstractions can lock people in and how we can prevent that. And we'll talk about how to make it easy on your contributors by giving them an easy to run test suite by giving them automatic feedback on their contributions. So I'm going to start by talking about QuickStart. So Sinatra, great gem, really great micro for probably the best micro framework, I think. Sinatra, really good gem. And take a look at this. This is the top of the Sinatra readme. This is the QuickStart. It's four lines long, which is amazing. There's four lines of Ruby. And then the gem install, which doesn't even count, and one line to type into your shell. And you're good to go. And this is what we should all aspire to, right? We need a QuickStart that's this easy. And that's what, as Ruby programmers, we expect. And we don't expect that because we're not smart or because we're lazy. We expect it because we want to spend our time building beautiful, functional, wonderful products, not installing things and configuring them. So having a really short, good QuickStart is actually, it's a feature of your code, not of your readme. You can't write a short QuickStart unless your gem allows it. How do we get to that point? Well, let's think about how we usually write a gem, right? So probably what happens is I am working on my application. I have some code that I think, ah, I should open source this. This would be useful to some other people. So I take the little bit of code out and I create a new directory for my gem. And I probably stick something like this into my gem file so that my application points at the local version of the gem while I'm developing it. And then I go on. I might write some tests in my gem. I might flush out the interface a little bit, start writing documentation. And at some point, I'll probably go back to my application and say, OK, well, does this all still work with this gem that it's now pointing at that I've been developing? But what I've never done at this point is actually feel what it's like to start using the gem from scratch, to start it in an application that doesn't use it already. So something that's worked really well for me is to just basically make an example app. It doesn't have to be a Rails app, whatever makes the most sense for the problem that you're solving. But make some sort of example app and really think, OK, if I wanted to do this, if I wanted to use this for some plausible use case, what does it feel like, what does it look like? I have always found at least one pain point that I can solve to make it easier to get started using this technique. So getting that quick start down is all about just putting yourself in the position of a new user, which is something that doesn't necessarily come natural. Now, once you've got the user hooked, once things are installed, they want to learn more. They want to be able to easily find out everything that your gem has to offer. So that's where documentation comes in. And we're back to Sinatra. Sinatra not only has a great quick start, but check this out. If we start scrolling down, we're still in the table of contents right now. Still in the table of contents. And then finally, this will take about a minute to get to the actual thing. Sinatra has an incredibly long readme. And that is a very, very good thing. So there is nowhere that's more discoverable for documentation than the readme, right? It's there front and center in GitHub. It's there front and center. When you have generated code documentation, it's there on airplanes. It's there if you don't have the internet, because it comes with the gem when you install it. So the readme is a really important place to give to lay out a full map of what your gem is capable of doing. And in order to do that, I recommend making the readme a part of your development process, just like, say, testing as a part of your development process. So you wouldn't submit a pull request, or you wouldn't even necessarily make a commit with new code that doesn't have some new tests. And you can take that a step further and say, I'm also going to submit a, any time I add something new to my application, I'm also going to add something new to the readme. And you can take that a step further and write the readme first.  Think about, how am I going to explain this to my users? And you might end up writing a better interface once you think about things in that term, than those terms, than if you document after writing. So the readme is really good. It's really important. Again, sort of every feature that your gem has, every major thing you can do with it, I think should appear in the readme. Very searchable. Command-F, great tool. But of course, the readme can't be totally exhaustive. The readme can't take you through tons of examples of every method. It can't take you through all the possible options you can pass, and that's what inline code documentation is for. So what we've got here is from addressable, another great gem. And addressable is using this param and return tag you can see here. And that is not built into standard RDoC. That is actually a documentation tool called Yard. So that stands for Yay Ruby Documenter. And Yard adds a bunch of extra structure to Ruby code documentation that isn't in the built-in documentation for Ruby. And what's nice about this is that Ruby doesn't have a lot of structure as a language. It's not statically typed. Everything's mutable at runtime. There's all this meta-programming. And that's great. It's really good for us as programmers. But it does make it difficult to communicate the nuance of how our code works to users who are experiencing it for the first time. So basically, the Yard tags act as a counterpoint, which has a lot of structure that can really explicitly communicate, hey, this is the type we're expecting here. There's no type enforcement. But this is what we expect you to pass to us. This is what we're going to pass back to you. And then it generates really nice looking documentation like this. So Yard has dozens of tags. These are some of my favorites. A particular importance, I would say, the API tag. So Ruby visibility, we can do some stuff with it. But we can't say make a class private. So the API tag allows us to say, hey, this is not part of the public API, very simply. Deprecated is another good one. So there's just one line, and you can mark a method. Don't use this if you're not already. Two of my other favorites are bang attribute and bang method. So we like to embed a program. And sometimes we define a method in a sense by not actually defining the method. So maybe we use def-delegator or active support delegation or any number of other things. Well, that's not going to automatically show up in our code documentation as being a method that somebody can call, but we can tell Yard, using this bang method, pretend there's a method here, and I'm going to document it for you, and then it just shows up as if it's a method in the documentation. So the effect is that Yard documentation can actually be, in a sense, more authoritative than your code itself, believe it or not. So the other advantage of Yard, kind of a freebie bonus type thing, is that rubidoc.info. Rubidoc.info is a site that hosts for free documentation for Ruby projects. It'll just pull the code off of GitHub or out of a gem. And it uses Yard, so if you do, you get this extra benefit, basically, for nothing. OK, so your users are now fully able to sort of get started with and understand your code, but we want to make sure also that your gem is not going to cause any unpleasant surprises. So I should be able to do, if I'm a user of your gem, I should be able to do this without a great deal of fear. And that means that I may be updating to a new version of your gem. I need to know what sort of pain that could possibly cause, and ideally not feel any of that pain. So the most basic way to communicate that information very concisely and in a way that is widely understood is to use semantic versioning. So semantic versioning divides versions into three numbers, like most versions look like this. Let's start from the back. So if I bump that green number, I bump it up from bugfix, or if I bump the bugfix number, it's called the patch level, that's communicating to my users that nothing outward facing is changing. So this is a bugfix. It's a patch to the code that maybe refactors it or makes it faster, but there's no outward facing change. So you really nothing to worry about here. Everybody upgrade at will, you're gonna get some sort of invisible benefit, but no outward facing change. The middle number, the minor version, means I've added something, but I've not changed anything that was already there and I've not removed anything that was already there. So again, you are totally clear to upgrade to say 4.3 here as long as you might not be able to downgrade because that might mean the future goes away, but you can upgrade a minor version safely. Finally, the major version, the red one, is breaking change. So anytime you rename a method, you get rid of a method, you change the types of the arguments that a method expects or the return value, just anything where your gem behaves differently for an existing public interface, you gotta bump that major version. But my claim is that, in fact, when we think about breaking changes, we're often maybe thinking a little bit too much about ourselves and not enough about our users. So typically we wanna keep things nice and clean. We realize that, oh, there's a better way to design this interface and I wanna make a beautiful interface for my users so I'm gonna change the way this method works or maybe I'm just gonna get rid of the old methods and write new ones. Well, that's nice for me as the developer of the gem, but my users are almost certainly feeling more pain having to go through their code and change from my admittedly worse old interface to my better new one than they would just not having to change anything. So I'm not saying don't make better interfaces, I'm saying don't get rid of the bad ones. We can take some inspiration from JavaScript here, the language itself. So ES6 is the newest version of the language that's actually beginning to exist in the world. And one of the things that they changed in ES6 was the scoping of variables. So basically we're all used to declaring variables with var. The scoping is kind of wack, it doesn't respect stuff like for loops or if statements, although that's the same in Ruby. But the point is they decided they don't like the way variables are scoped and so they wanted to change it. Now they could have just changed it, right? But that would have broken existing JavaScript code and it would have meant that you needed to opt in and say and explicitly say I am now in ES6 mode and so you can scope variables in the ES6 way and that's a common understanding we have. But instead, thanks to this blog post from a few years ago and the idea of one JavaScript, JavaScript community basically decided we are going to always support every old version of JavaScript in every future, sorry, all old JavaScript code will be supported in every future version of JavaScript. And the way they solved the var problem is they just made a new keyword for declaring variables that have better scoping, which is let. So now basically you're not supposed to use var, you should never use var, it's deprecated, I mean you can if you want, you'll always be able to. But JavaScript solved this problem by leaving kind of this, by dragging this trail of cruft along with it. And so it is very crufty to have two different ways of declaring a variable only one of what you're actually supposed to use but in the end they're doing a real service to everyone who's written JavaScript code to date because they're not breaking anyone's code. So we can take some inspiration from that. Sometimes you gotta make breaking changes but probably not as often as you think. So now let's think about the environment that our gem exists in, right?  So it's important that we play nice in the larger environment. We have at least one dependency ourselves which is Ruby, right? So we depend on Ruby, we probably depend on some Ruby version or we're compatible with certain Ruby versions. And chances are we also probably have one or two gems that we depend on. Maybe we do, maybe we don't. But on average we do. So it's important to think about how tightly we're specifying what our dependencies are. So this is something that we could put in a gem spec but that would be a bit horrifying. So essentially an exact version of active support. It means if you want to use a different version of active support and you want to use my gem, you are out of luck. And it's very unlikely that this is necessary so you would have to really, really, really, really not trust the developers of active support to use semantic versioning and not make random breaking changes to be justified in using such an exact version constraint. So we can get a little looser and we can say, okay, well, any 4.2 will do as long as it's at least 4.2.4. But again, semantic versioning, if we all agree on this it tells us 4.3 is fine, right? 4.3 will only add features that won't remove or change them. So what I can do is I can say, okay, I'm now gonna depend on at least 4.2 but any 4.x is okay. Now I don't know that five is gonna be okay. I don't know what five is gonna have and I know that five will break things because that's the definition of being five. But I can at least, this is as far into the future as I can look with my dependencies and still be safe knowing that my gem won't be broken by a change in my dependencies. So that's fine and now we're as future-proofed as we can get but in fact, the truth is not everyone is using active support 4.2 right now. So you're still saying to your users you have to be on the latest version of Rails for this to work. And it's unlikely that you really need to say that. So for instance, 4.0 is probably fine. That's good. Maybe you have to do a little bit of extra work to support 4.0 but the truth of the matter is a lot of shops, a lot of applications and projects aren't always able to keep up with the latest versions of things all the time. And so you're gonna make your users lives much easier if you can be as loose as possible about your version requirements. And I would even say, you know, if we're talking about Rails right now today it's likely you can do this because things haven't changed that much in active support between three and four. So do what you can to support as far back as is reasonable and then as far forward as you know something won't break. And like I said before, we, you know, even in this constraint we don't support Rails 5. We don't support active support 5. So how can we know when that is a problem? So I, you know, I could release this today and that's fine but then at some point in the future Rails 5 is gonna come out and maybe I'm not totally, totally paying attention to that. And so I could suddenly have a gem that has dependencies that are locked in. Happily some kind soul or souls has created a service called Gemnasium which will automatically audit your gem's dependencies and it will send you an email alert if you are out of date now. So here's the, here's part of the report for the multi JSON gem, great gem. And Gemnasium basically means you don't have to worry about it. You can be, you can respect the future because in the future you're gonna know right away, oh hey I gotta try this out with Rails 5 and see if anything's broken and then bump the dependencies. But that see if anything's broken that's kind of the hard part, right? I mean it's one thing to say I support lots of different versions of the same dependency but does it actually work? So of course we want to run our tests against all of the things we say we support. So all of the versions of Ruby we wanna support. All of the versions of other core dependencies we wanna support, stuff like Rails, RAC, Event Machine, whatever it happens to be. But particularly we wanna be careful about these very popular, very important gems that almost everyone's using. And so Travis is a great tool to do that. Travis is hosted continuous integration. It will, few lines of configuration and it's gonna run your gem's test suite against whatever Ruby versions you want including JRuby, Rubinius. It's not limited to MRI. It will run it against a set of gem files. So you can have different gem files, different bundler gem files that specify different gem dependencies. And you can even have it just pick arbitrary environment variables that your test suite understands. So here you can see this devise ORM. It's a little hard to see but you can see this devise ORM that is devises using to run it against Mongo and Active Record. So Travis is really nice. Travis is hosted. Travis integrates really well with GitHub. So when somebody makes a pull request it will automatically put in that pull request whether or not the test suite passed on Travis if you haven't hooked up. Of course you still might wanna run your test locally. WWTD is a great gem for doing that. So that basically reads your Travis configuration and then does the same thing running the test on your computer. It'll use RBM for RVM or JRuby to do the different Rubies. So that's very nice. So now you have both the local copy for when you're on airplanes and the cloud hosted copy. Now I mentioned just a minute ago that Travis is really good at running against different gem files but you probably don't wanna maintain a bunch of gem files by hand. So I recommend another tool called appraisal which allows you to just write one file that lists all of the variants of your gem dependencies you wanna run again. So for instance here you've got four different versions of Active Record that are specific in the appraisals and this will actually generate four different full gem files that you can then give to Travis. So it just varies the part that you wanna vary. That is put that all together, right? You get the appraisal gem files, put them up on Travis and you suddenly have a very robust system for ensuring that you actually support the stuff you say you support and that when you change a feature or change some internals you're not breaking it on any of the platforms you support. So that is dependencies and versions and not breaking things. There is a little code in this talk. Here we go. So let's think about social networks. Two social networks you might be familiar with are Twitter and Facebook. There are great gems for each of them. So there's a gem for talking to Twitter called Twitter and there's a gem for talking to Facebook called Facebook and I wanna talk about those gems. We're thinking about designing public interfaces. So the public interface is the part that we, basically when we say we're not gonna break stuff, that's the stuff we're not gonna break. Let's look at Twitter first. So if I wanna write a tweet, this is the method I'm going to call. So it's a method called update. I pass it a string, that's the body of the tweet, I can pass it some options if I want and that's really nice. That is a fully nice little wrapped up abstraction for me but if I wanna poke my friend on Twitter using the new Twitter poke feature that begins to exist next week, that is actually not something that the Twitter gem supports because it doesn't exist yet. So in that case I might wanna go down to a lower level and in this case I'm looking at the code for update and I see that okay there's this perform request with object, sorry perform post with object. And that looks like a nice little level interface so I can dig a little deeper and get to this perfectly nice generic perform request method and all this is doing is sending an authenticated request on behalf of a particular user to the Twitter API and kinda giving me a nice response. So this is a much lower level thing than that update method we were looking at a minute ago. So this would be perfect, right? I can make a poke request through the using perform request here except this is not part of the Twitter gem's public API. This is a private method. So we kinda have this call trace that looks like this. We've got a nice public update method to do one specific thing that the author of the Twitter gem expected that I would wanna do correctly. And then we have some private methods that are at decreasing levels of abstraction. So lower and lower, more generic, less wrapped up and packaged up nicely. But another way that one might think of this kind of gem when you're writing it is first I'm just gonna write a gem that lets me make authenticated request to Twitter without any real high level knowledge of what the Twitter API, what the resources are, what the endpoints are. And in that case perform request would actually become one of the main interfaces to that layer of the gem. And then on top of that I would essentially use my lower level library which is fully tested, has a public interface that's stable to write a nice high level bunch of code. And really the effort that must have gone into this gem is incredible because it does support basically everything you can do with the Twitter API is explicitly contemplated in this gem. I can go crazy like that. So this is sometimes referred to as a layered architecture. Another way to think of it is essentially I'm eating my own dog food but I'm also just letting you have the dog food if you want, so dog or dog food, either way. That makes perfect sense. Another way I might choose to approach this problem though is to think, well, can I just get away with this? Can I just get away with perform request? Do my users really need this high level kind of domain model, which again is really beautiful but is that necessary? The Twitter API is pretty easy to understand. And that is the choice that Koala makes since the Facebook gem. So Koala has this put connections method and put connections basically is the equivalent of that last method we were looking at. And this is the highest level of abstraction Koala has. So Koala does not know what resources are available in the Facebook API. And that lets it be first pretty lean. And second, when Facebook introduces some new features in its API, as long as it's not some totally new structure for the API, which it pretty much never is, Koala is instantly up to date. So I still prefer this one really. I mean, this is the best if you got that kind of time. But you can also maybe do your users a big favor by just giving them a low level API that they can work with that takes the boilerplate out but doesn't necessarily provide the full abstraction. So the quick start is to your users what the test suite is to your contributors. If I wanna contribute to your gem, the first thing I'm gonna do is check it out and try to run the test suite. And if I can't, if I get frustrated, I'm not going to have a ton of patience for that. And it's pretty likely that I might just sort of keep my, keep my branch and never contribute it back because I can't prove to you that it works with the test suite, et cetera, et cetera. So it's really, really important for your contributors if you wanna have good contributions to make sure that your test suite is really, really easy to run. So it's unlikely that you can just do this. It's unlikely that rake test alone will just work, but it's definitely possible that bundle and then rake test is sufficient. And this I think most gems will be able to provide this. So the key here is you already use bundler to manage your applications runtime dependencies. Just use it to maintain your gem's test dependencies at runtime in the same way. So very simple way to do this, you have a gem file. You can just say use the gem spec, just this one line gem spec. Use the same gem, use the gem spec that's in the directory we're in right now and bundler knows what to do. Then in your test code, in your test helper, spec helper, you can just, that first line require bundler setup. And you're good to go. And bundler loads in the gem environment and installs everything for your users. And so if you don't have any external dependencies if you're just sort of like a Ruby self-contained library here, then now your users can very consistently and nicely run tests. If you do have external dependencies, so say you need Postgres, then bundler can't deal with that for you, right? Bundler can give you the Postgres library, but it can't give you an actual Postgres instance to test against. So my favorite method of getting this to my users, to my potential contributors is using Vagrant. So Vagrant is a tool for managing virtual machines like virtual box, specifically for development environments. So it's mostly used to sort of have a repeatable development environment for a team that's working on an application, but it's actually really good for having a repeatable test environment too for a library. So if I wanted to, if my tests require Postgres, then I can ship a Vagrant file. They could be as simple as this. Basically, we're using Ubuntu. We are installing Postgres when we first spin up the machine, and then we're gonna forward the Postgres port to the host computer so my tests we can actually interface with it. And that's it. And now instead of having to go through a bunch of instructions saying, okay, well we expect Postgres to be on this port, so go ahead and just deal with it. Potential contributors can run Vagrant up, and they've got the environment that allows them to run the tests. So that's really nice. Now, of course, being able to run the tests is one part, actually writing the code is another part if I have contributors to my project. And a few things are more heartbreaking to me than getting a pull request that it's a good new feature, say it has a nicely factored code, really just everything I want, except maybe I see something like this. Now, I know this is hard to look at, but I would never put a multi-line block with curly braces, but I respect the decisions of those who do. And I would hate to be in a situation where I got a really good pull request where there's some style nitpick I have. And so instead of saying, hey, thanks, and accepting the pull request, I have to say, can you change that to a do end? And then I'll take your free work that you're giving me for my library. So can we avoid this? Yes, RuboCop is a tool for style checking and linting. You can set up rules like these, there are more. To your preferences, right? It's your library, it's your piece of software. So you get to decide what the style is. And the nice thing about RuboCop is that it's automatic, it's not coming from a human, it doesn't feel like a rejection, it just feels like a cold impersonal robot being cold and impersonal. And it's very quick. So you can take the RuboCop, you just run RuboCop basically once you set up these rules. And you can put that in your Travis configuration so that when somebody submits a pull request, they'll see feedback right in the pull request saying, hey, the build didn't pass, go look at the build report. And then that shows where the style and style doesn't match your style or there are various linting problems. So then you get to have you kick, right? You don't have to have weird confrontations with contributors about things that are completely a matter of opinion, but you do get to have nice consistent style in your library. So that was number seven, and we are at the end. So real quick, just to recap, write a gem that has a really short quick start. And the way to do that is try it yourself. Wait a really long read me, use Yard for code documentation. Try not to ever, ever, ever do breaking changes if you can avoid it. If you cannot avoid it, be sure you use semantic versioning to communicate what's going on to your users. Understand that your users are probably using old versions of things, at least some of them are, and support the past as much as you can, as well as supporting the future as much as you can. So keep track of new versions of things with gymnasium, run your test suite against lots of different versions. Use Travis for that. Avoid abstractions that can lock people in to your assumptions about how they're gonna use your code. So consider providing multiple layers of public interface. The nice high level one, but also an equally valid, equally public low level one. Make it easy to run the test suite by using tools like Bundler and Vagrant. And finally, use RuboCop to give instant and non-confrontational feedback on code style to your contributors. That's it, got plenty of time for questions here. Right, right. So the question was, the first part of the question was, you're wrong about RuboCop. And the second part of the question was, what about a contributing document? That is a great one. So in terms of the contributing document, basically you can make a file in your repo called contributing.md, all capital contributing, I'm not sure if that actually matters. And GitHub will put a banner at the top of the form where people submit pull requests and issues that link to that document. So it's kind of in people's face right when they begin to actually attempt to contribute and you can write whatever you want such as follow my style. On the question of RuboCop, yeah, sure opinions may differ. I guess I would be interested maybe after we finish here to hear what the objections are. If you're uncomfortable with the idea that the build should break because of style issues, then RuboCop can also not be a part of the build but still be there for people who are trying to match your style. Do I have a suggestion on which license we should use? MIT, seems like the normal one. Yeah, a copy left doesn't seem to be enforceable but I'm also not a lawyer. So yeah, I guess I don't really have an opinion but I do MIT because that's what everyone else does and yeah, usually is a good idea. Okay, for those on the other side of the room, avoid multi-license gems, pick a license, have that be the one true license. In my experience, what is the best way to publicize a gem? Ruby flow is good, I've had good luck with that.  I mean hacker news, Reddit, Ruby subreddit, if you're into Reddit, Twitter. But Ruby flow is probably the only one that maybe is a little under the radar but I've had pretty good responses from that. Yeah, that's a good question. So the question is for versioning, what is a good practice for the first release?   I would say like, okay, let me just back up 1,000 slides here. So if you are at this point where you like haven't pushed it, then an 0. is cool. I would say after that, just go for it, you know, 1.0. Like when you're going on Ruby flow and Twitter and stuff, like you could always make it 2.0. It's not gonna hurt anyone. Sure, that's a great question. So the question was if I release a new version of my gem that supports Rails 5, what kind of release is that from my gem? So I haven't made any other changes, but I have, you know, let's say, for instance, I actually don't have to change my gem to support Rails 5. Then I would say, yes, that is a patch level release. I guess it's hard to imagine a situation in which, I mean, you can imagine sort of augmenting an API in some cases so that, okay, now I can take a new type as an argument for a particular method. And I guess that would technically fall into the minor version release. You're like adding functionality to the public interface. So yeah, I would basically sort of evaluate it on the merits if there's no change to the public tracing interface at all, then it's a patch level. Otherwise maybe it's a minor. Okay, so the question is if another gem maker defines a particular namespace, like it uses a module to define a namespace, should you use that namespace or should you define your own? I assume we're talking about a case where your gem is kind of an addition to this like a plug-in of some sort to theirs. Right, so I think in most cases where that comes up, certainly the initial developer of a gem can establish a convention that this area of my gem's namespace is for you to put your stuff in. I'm thinking of like a rescue here has some good conventions around that. I would say if there's not a really well-defined convention by the sort of upstream library that you're building against, there's very little downside to just respecting the general rule that like the top-level namespace of everything in my code is the name of my gem in camel case. Ah, can I say a few words about the underscore versus the dash in the naming? So like mostly use underscore. Underscore is how we name our files obviously. In the gem file, you know, when we put gem whatever, RubyGems is gonna look for the underscored version, like it, or it's gonna look for the same thing that the gem's called basically. So dashes are a bit suspect. I would say actually the scenario we were just talking about though, where your gem is building on the namespace of another one, that's a situation in which I would probably go with the dash, so I might, if I have like, you know, rescue like tparty, then I would probably do like rescue dash t underscore party, and then you know, like the sort of root of my library would be rescue slash t underscore party in the file system. But I don't know, it's the Wild West out there with those dashes. You gotta offend for yourself, what's up? How do I test my gem's compatibility with dependencies? Do you mean like Ruby dependencies or external ones? Oh, so that's what appraisal's for. So, oh, right past it. So appraisal allows us to just list all the different versions of different dependencies that we wanna test against, and it generates an exhaustive set of gem files that we can then, using Travis, run our tests against. Yeah, so the question is, if you have a gem that depends on Rails, and it's sort of like baked, it's really a tight part of, or Rails is a tight part of using it, how do you test that? How do you generate a full Rails app? I personally have written a lot of gems that sort of hang out at the model layer, and I will say there's absolutely no need to do that if you're doing it at the model layer, like ActiveRecord is its own thing, and you can just test against ActiveRecord. And I don't have any great advice for if you're writing, like, if you're writing a view layer thing that has a bunch of helpers and you wanna test those helpers, there may be no way to get around actually doing that in a real Rails runtime. I'm a little embarrassed I don't have any good advice for that because it sounds horrible and I would never wanna do it, but maybe there is a good practice out there and maybe the internet knows. Cool, so the question is, hoe, bundle gem, Ruby gems, tasks, jeweler, so these are all tools for bootstrapping a gem, and my feeling is basically, definitely not hoe, definitely not jeweler, basically like the level zero thing is writing your own gem spec is really easy, it's just Ruby code, and there's definitely no need for anything that generates a gem spec, like you don't need code that looks almost exactly like the code it generates. I actually, I skipped this slide, but I do like bundle gems pretty good, where did I put it? Anyway, bundle gem is a command that just generates a nice skeleton of your whole gem environment, including all the stuff about, there it is, including all the stuff about integrating bundler into it, so yeah, I think you don't wanna literally have to sit there and make the lib directory every time and bundle gem's nice for that, but I would avoid anything that is trying to add a level of indirection on top of say, making your gem file, like your gem file can just be your gem file. All right, should we call it? Let's call it, thank you everyone.


So, what I want to talk to you today about is the more specific case of Mozambique. The title is Anatomy of a Jobs Crisis Mozambique. So I guess I'm taking down from the more general discussions we've heard from the previous two speakers and looking particularly at the specific case of Mozambique. This is work that is, this talk is loosely based on some work I've been doing with Fintarp over the last few years. On the wider website there's a paper that came out, I think at the beginning of this year called Something Like Understanding Mozambique's Growth Experience through an Employment Lend. So, if you're interested in reading a bit more about Mozambique and some of the material about Mozambique is in that paper, I would encourage you to do so. So, as an agenda for my brief talk, I just want to talk a little bit about what we mean by jobs crisis, then look more specifically about what we know about the situation in Mozambique and then think a little bit about what can be done. I don't want to be too ambitious in terms of claiming that I have some set of policy recommendations that's going to revolutionize Mozambique's job situation, but at least some food for thought that perhaps could help lead into the discussion. So, the focus, the questions, so turning that around and saying, well, what am I actually trying to do here?  And I think the previous speakers mentioned a little bit that there has a lot of different nuances to the idea of a jobs crisis. So it might help to think, well, what do we mean in this specific case? And then I will show you what I think is the nature of the jobs crisis in Mozambique. And as I said before, look at what might be done. So yeah, we often use the term jobs crisis in many different contexts. It's easy to go to the US and the UK and hear jobs crisis from one day to the next. But do we always mean the same thing? No, I think there's three broadly main uses of the term. So the first one could be seen as the idea of a crisis of high cyclical unemployment. You had a lot of jobs, you lost jobs. It's a jobs crisis. It's just an idea here taken from the US, a large number of vacancies and a dramatic increase in vacancies associated with the global financial crisis. Some countries have done better than others in coming back to pre-crisis levels. But that was in itself a jobs crisis. The second form of discussion of a jobs crisis is more of a structural form. In economics we can sometimes speak of a beverage curve, which is the relationship between the number of available vacancies in an economy and the rate of unemployment. So the first crisis would be about we're down at the bottom of the curve and we want to move back up it in a sense. So you want to have more vacancies available and less unemployment. But the structural issues in the labour market are often about the position of the curve itself. How well matched is the demand for workers with the supply of workers? And we often hear of a skills mismatch. Again, this is often heard both in developed countries and developing countries. I was just reading yesterday about some people claiming that there's six million graduates in China that can't find jobs because there's a difficulty in matching the demands from the labour market, demands from firms with the supply of educated workers. So this is just an example, I can't actually remember where it's from. But again, giving you a sense that there's a mismatch in terms of opportunities and available workers. Lots of people who are potentially available to work in construction chasing a few jobs and less so in education and other areas. The third form of the discussion of jobs crisis is something along the lines of jobless growth. So the economy is ticking along nicely, doing very well, thank you very much. But it's not producing jobs at the same rate as growth in the economy overall. This is often being discussed for a long time with reference to India and this again just gives you a little sense of that. So between 2004 to 2005, so if you look at the bottom line there, you see growth in India was extremely high, around let's say an average of around 8% over that period. But between 2004, 2005 and 2009, 2010, only 5 million workers were added to the economy in terms of formal sector employment. So there's something going on there and that's often been discussed as this crisis of jobless growth. So I think the issue to just bring to your attention perhaps, I'm sure you were all very much aware of it already, but is to say that jobs crisis means different things in different contexts. And so we need to be aware of what form the jobs crisis is taking and what is the relevant context and aspects of that in that situation. And just to discuss a little bit more about jobless growth, of course that's more often not exclusively applied to developing countries. And here we often hear about challenges of structural transformation in which the benefits of growth are not producing higher productivity jobs. And in particular it's important to note that in three, the jobless growth situation, it's not necessarily the case that people aren't working. People do have economic activities, they're too poor not to work. The problem is persistent levels of underemployment. I think you've probably guessed now what I'm going to talk about with respect to Mozambique, right? The short version, and what I'm going to do in the next slides is just go through point by point with a little bit more evidence. But the short version for those, the short version of the story is that Mozambique has achieved a very impressive recovery and continued economic growth after a protracted conflict that started in around the late 1970s and ended in 1992. So since that period of time, growth has been relatively consistent and at a high rate. For in many respects, at least until recently, Mozambique has been called a donor darling. It's achieved a lot of improvements. There have been improvements in welfare but at the microeconomic level, poverty reduction we can say has been relatively modest and some concerns have been raised regarding the quality of growth. And in particular, once we start looking at the nature of structural transformation or where people are working, we find the structure of employment has been relatively stagnant. In fact, a little bit linking into what Carol said, we see large and widening productivity differences between economic sectors. So rather than productivity coming together, we see actually the opposite. And as a result, we don't see the signs of positive structural change that we would normally associate with high levels of sustained growth. And in addition to that, the demographic pressures are mounting and quickly, so the challenge is becoming even more acute. So just to put some meat on the bones of that short version, here's a graph that shows the macroeconomic success of Mozambique. As we can see from in the 80s, basically growth was pretty choppy and actually declined in per capita terms. The bar is just a measure of US dollar per capita income and the red line is the real growth rate. But as we can see from the early 1990s onward, incomes have been consistent and growth has been more stable at a robust level. Great, well done Mozambique, Tic. But let's look at what's happened to output. If we look at the structure of output, so which sectors are producing more or less output? We don't see so many changes. We see that agriculture remains an important component of GDP, at least approximately around 30%. It has reduced a little bit. So these sectors are now the largest sector by output and we see what's often described as a missing middle, relatively small manufacturing sector, that's the green bar, increased a little bit in the mid-2000s. That was actually associated with one very large firm basically that entered. And mining has recently increased as a share of GDP associated with particularly with coal but also with some large-scale gas investments. I'll talk about that in a bit. But as we can see, no dramatic shifts in terms of the composition of output, what is being produced by the economy in broad terms. What about where people are working? So where people are working, we see a continued very large percentage of individuals in agriculture. So roughly three out of four members of the working-age population are working in agriculture, broadly speaking. What we mean by agriculture is essentially smallholder, small-scale farming. What we have seen is a moderate shift into services. But as we can see, if we just go back on slide, we see an increase in the number of people working in the services industry but actually no major change in the production of that industry, the relative production of that industry in relation to the rest of the economy. So essentially what that means is that the labor productivity, the relative labor productivity in services is falling. So the idea, and I think this is important to understand, what we've seen is a shift of workers out of very low productivity agriculture into low productivity services and the productivity of the services sector is falling. So in a sense, we have a concern that perhaps we're getting a saturation of individuals into the service sector and by services, that's obviously a wide range of activities, but a lot of services in Mozambique are informal commerce. So people might be, to put it crudely, you're going from the farm to selling tomatoes by the side of the street. Actually, you get more money for selling the tomatoes, unfortunately, but it's not the kinds of fundamental structural transformation associated with a more sustained progress. This graph probably may be a little bit difficult to work out. So this is relative labor productivity in each sector. So relative to the average, which sectors have higher or lower labor productivity? And as we can see, here, we actually have the bars widening. So they're going away from each other. So if sectoral productivity was coming together, so similar levels of labor productivity in each sector, we would see those bars coming together. We see widening and in particular driven by mining. So the growth of the mining sector that I mentioned here going from around 2% in 1996 to 9% in 2014, this is by production, hasn't been associated with lots more people working in that sector. In fact, less than 1% of workers work in the mining sector. So what that means, in fact, is that the productivity of labor has jumped dramatically in mining, but it's actually lost workers as a share of the total number. So the share of workers in the economy in mining has fallen over time. Again, this just gives a sense of where things are going in the economy. I don't think we need to get into the details, but the underlying story here is that there hasn't been a trend of positive structural change in the labor market, and that is an ongoing concern. So added to that, so that's a snapshot of where we are today, up to 2014, 2015, when we have the latest data, the concern is what's going to happen in the future. And one of the challenges in Mozambique and like many other sub-Saharan African countries is that fertility rates have been high. Even in the latest DHS survey, the expected number of live births per fertile women was still around five. So that's the average expected number of births that women are expected to occur, and that hasn't fallen much over time at all. And so what that's done is that is locking in for a generation, basically of a relatively high population growth, by definition. It's a certainty that this will occur, essentially. The projected population size in terms of the working age population is going to go from around 12, 13 million today, and that's going to easily double in size within a generation. And here, in addition to that, what I've shown here is the total working age population with projected levels of education. So today, well, 2010, six years, well, 2015, 2010, we have roughly 10 million working age individuals who have not yet completed a full cycle of primary education. They may have done a few years, but dropout rates have been very high and access has been problematic historically. So the majority of working age people in Mozambique don't have a completed primary education. That is improving, but clearly it's just an improving slowly. And even if we project at the most optimistic rates of what can be achieved in terms of improving access and ensuring that dropout rates fall, it's still very likely to be the case that within a generation, still the majority, the majority of workers have not completed a full cycle of education. So that's a challenge. So the challenge is not only significant population pressure looking for jobs, we also have the challenge that they are largely unskilled or low-skilled in general. Just to put some more numbers of that, we could think about, how quickly would the formal sector have to grow to absorb the number of new entrants coming into the labor force? So it was interesting to hear what Carol was saying about the importance of large firms and they're more productive and they do create higher quality jobs. I totally agree. The challenge is that in a country like Mozambique, you can name the firms. So even if every single large firm in Mozambique was to, let's say, double its employees every year, that would be a drop in the ocean in terms of the numbers of individuals coming into the labor market. I'm being a bit colourful, perhaps, with the language, but just to give you a sense, right? So if we look at these, again, these are kind of thought experiments. They're not strict projections. But in terms of a thought experiment, if we look at the formal sector growth rate of employment of around 3%, so that's what we've been seeing historically around, 3% additional in terms of the formal sector, we would actually see the informal sector continuing to rise in absolute terms. So if we keep on going where we are and the formal sector keeps ticking over, keeps creating some jobs, and the rest go into the informal economy, agriculture, petty services, and so on, we would see the absolute size of the informal sector double. At a 5% growth rate, so that would be much better than it is now, 5% growth rate of formal sector employment, it would still be rising and would only be peaking by about 2050. At an 8% growth rate, so if formal sector employment was growing by 8% a year, so much higher than the rest of the economy, we'd still see growth in the informal sector until around 2030 when it would peak and then it would start falling, so it would reach a tipping point and then fall. I mean, these are broad, very crude back of the envelope calculations, but it just gives you a sense of the magnitude of the challenge. So even if we get the formal sector really rocking and rolling, really producing and generating new jobs at a fantastic rate, the reality in a country like Mozambique, and I'm not trying to say that every country is like Mozambique, the reality in Mozambique is that at least for the next 10, 15, 20 years, we're dealing with a growing informal economy. Okay, so what can be done? Well, I think when we start thinking about policy interventions, I think it's helpful to distinguish between what we might call microeconomic or very narrow style interventions versus the interventions that operate at a macroeconomic or structural level, thinking about what is the nature of the growth, what is the pattern of growth occurring in the economy. And I think I probably have hinted already a little bit at it. Of course, the latter in Mozambique, we believe, is more critical. The reason is it's because the challenge is really so large. And also because the nature of economic growth over recent years has been problematic. So just to round off, I just want to just give you a sense of where... I'm not trying to say this is where growth has come from, but over the last, probably last 10 years, we have seen a huge explosion of FDI to Mozambique. And this is an estimate of the stock of capital, the stock of capital financed by domestic credit, not by domestic equity, we don't have that, versus FDI. So there has been a huge shift of FDI into Mozambique, and the stock of that FDI has grown hugely. Where has it gone to? Well, it's gone into, no surprise, extractive industries and largely transport communications. If you look at the green bar, you might just be able to see at the bottom, it's very difficult to see. So really, the vast majority of external investment has been pumped into what you might call relatively capital intensive activities. And that helps understand a little bit of what we saw in terms of the labor productivity challenges, given that remember, three out of four workers are in agriculture. So in terms of what we can do, well, I'm not going to go into details, but I think we should think about three areas. Well, first of all, we have to think where are people working and where are they likely to be working over the next 20, 30 years? I would love to see growth rates of the formal sector employment higher than 8%, higher than 10%. That would be wonderful. And I think that is possible. But at the same time, the feasible areas for some of these large scale formal isn't always in labor intensive sectors. And where workers are really is in agriculture. And it's very difficult to see any form of significant changes in terms of the jobs crisis, in terms of reducing poverty without a more serious and considered attempt to address productivity in agriculture. We can talk a little bit about what that might mean perhaps in the discussion. There are also what we have described as anti-job policy distortions. So there are certain policy, I don't know what the right word is, policies out there like minimum wage legislation that would seem to inhibit job creation. And that is a concern. And overall, a little bit what Carol was saying, raising external competitiveness. So how do we do that? Building better infrastructure, making sure that exporters can get their exports out, making sure that imports can come in quickly so that you can develop that kind of opportunities for trade that weren't there in the past. Yeah, I'm not gonna summarize what I just said, but I do want to bring into attention the fact that Mozambique is now facing a major crisis. So what's all that about? Well, devaluation of 100% in the last 18 months. Huge challenges there and of course that has meant that some of the big investors, the FDI has been on hold. But at the same time, I do believe it could be, could be a window of opportunity to boost labor intensive export sectors. These are the kinds of policy shocks that although they are extremely damaging in the short term, do provide some windows of opportunity to reset the economy and find a new path. I look forward to seeing those opportunities being taken. I'll finish here, I think. Thanks very much. Thank you.


Former Prime Minister of the United Kingdom, Winston Churchill once said, healthy citizens are the greatest asset any country can have. Guys, welcome to the Advocate. Today, we're going to be sharing with you thought-provoking topics as usual. It's going to be an exciting conversation. We basically call a spade by its name. Guess what? The deployable state of Nigerian's healthcare system is at the top of our list. And I'll be sharing with you some thoughts on what I think a Nigerian life should mean. We're also going to be taking a look at unemployment crisis in Nigeria. And just imagine the number of unemployed people today. Uche will be here to share thoughts on that. Toye will be advocating for the representation of Nigerian and African books. And finally, our very own friend Kunle Lawal would open up a can of worms. And guess what? Middle-class circumverts the Nigerian democracy is going to be his topic. Guys, sit back. After this break, we'll be back to dissect this topic. Stay with us.  A drunk Okada driver. Now, after excessive delay, she was finally taken to the hospital. By the time they arrived at Lute, it was 48 hours after. And guess what? Her family faced a grim reality. They lost her on Sunday, 21st, 2001. When they arrived Lute, a lot of things unfolded. First of all, there was a lack of beds. The syringes and the glows and everything else that you had to use in hospital. The family was asked to pay for them. Imagine buying the syringe your daughter would be used. But guess what? Everything they spoke about mirrored an extortion than a healthcare facility. And this is the reality of many Nigerians. The story of the coaches is one that reminds us of every Nigerian is one crisis away from death. The state of healthcare in Nigeria is very deplorable. About 3.2 million out of the 200 million Nigerians today are covered under the national health insurance scheme. Just imagine that number far less than 10%. Access to quality health is still a nightmare for many Nigerians. While our educated officials have the luxury of student wealth to fly abroad for expensive medical treatments, our underfunded healthcare sector continues to decay. Now, with health sector only receiving 4.6% of our national budgets every year. You can imagine, if you break it down, that's somewhere around 2.9 billion is allocated to medical care every year in Nigeria, with a population of 70% under 35. Countless efforts have been made by the African Union and the World Health Organization and many others to persuade the federal government to increase healthcare budgets. But yet nothing has been done. What has it cost to put a primary healthcare center in every local government? What has it cost to put a special hospital in every sanitary district? The lives of our people have to matter. Quality healthcare is not just a benefit reserved for the privileged few, but rather a fundamental right for every Nigerian and every citizen. We therefore urge the Nigerian government to emulate its foreign counterparts and make concerted efforts to offer comprehensive universal healthcare to its citizens. We also cannot forget to hold accountable the custodians of our healthcare sector, to our doctors and our nurses.  The level of dedication and diligence that you show is very important to determine life or death. For a healthcare professional in any capacity to lose empathy is to undermine the very virtue upon which your profession is built. Medicine without empathy is no medicine at all. Every healthcare worker who owes you owe your patients a duty of care and if the quality of service given falls below the standard of care, it amounts to a medical negligence that can also be persecuted. But if we continue to undermine the lives of our people, we are going to be breaking the act of 2004 medical and dental practitioners and it has been passed into law. We cannot continue to ignore the rising polls of avoidable deaths in the stravestical healthcare sector. Remember the lady that we lost her to, I think, Prime Medical Center the other time? Remember the other guy that was rushed to hospital and they asked him to get a police report and he passed before they could get one? Why would you delay a victim to healthcare because you need a police report? I mean, put him on the chain, he's not running away. However, we can, for the protection of the lives of every Nigerian child, continue to advocate that we have to make healthcare work in this country. The lives of Nigerians are not ours to waste, it's ours to protect. I open the floor. Well, Fadi, one of the key things I find interesting was when COVID occurred and our VIPs couldn't leave the country again. So, COVID was kind of like a blessing or a pointer for us to decide to look into our health sector and start to ask the real questions. We lost some VIPs on the way during COVID, not like we do not commiserate with the families, but it put them in the exact position the common man in Nigeria has had to face. But then it's ironic because we missed the perfect opportunity to fix the healthcare sector at that time. A lot of the states, we saw pictures of many of the states who were put in tents when they could have used that as a chance to roll out community healthcare centres or even one super mega hospital in these locations and in these regions. So, it leads me to wonder what exactly is the problem? Is it the lack of funding? Is it just the strategic outlook on how these things are supposed to be done or is it that we've just lost our conscience completely? Well, I think I can speak to it in that I have a child with a medical condition. So, I deal with the healthcare system on a weekly basis in Nigeria and recently I've had to deal with the public healthcare system due to her diagnosis and due to the fact that the best endocrinologist in Africa consults at Luther. And it's a daunting experience. It's a depressing experience. As the first time that we went, the first week that we went, we were literally all in tears when we left. So, you know, there's two ways you can look at it, right? In that, yes, healthcare professionals are maybe neglecting their role. But they're also existing within a structure that is not set up for them to succeed. So, there are people there who really want to do their job, but they don't have the ability to do it. So, let me set an example. We are due to go to Luth to sleep over. I told them, I'm not going to sleep over. There's no way. We have transport. We'll get there as early as we need to get there. Because there was... In one of our visits, I lost my way. Luth is massive and ended up entering the ward, the general ward. And I wept at what I was seeing. Like, leakages, just filth. I mean, people on top of each other and it was terrible. And then I got the report saying, okay, we're going to be sleeping over. This is what we need. I need to go to the lab and pick up the tubes, pick up the injections. I need to go to the pharmacy, go and get the drug that they're going to inject her with. And I was confused. I'm like, what do you mean? Because me, I'm coming from private healthcare. What do you mean? I have to go and do those things. Oh, yes, because we don't have those things here. And you have to buy them? You have to buy them. We spent two days looking for the drug. I called pharmacists. I knew I called so many pharmacists. I called everywhere. And I had anxiety in my throat for like two days. So just imagine someone who doesn't have any other choice. My friend who lost her sister said, my sister did not die from the accident. She died from negligence. If the response had been quick enough, she would have survived. So just imagine and then they had money, even at the end of the day, before they could take her to the mall, they had to pay. At every point in time, it was about bills, bills, bills, bills, bills. Just imagine that not very many Nigerians can afford three square meals and you're not having to pay exorbitant bills. We understand that the private hospitals are also there to make profits as well as to run. But I think when there is a medical emergency and there has to be a way that they have to put the life of the person above, pay for your card, pay for this, those things can happen along the line. And I really want to see persecution if you ask me. Negligence, criminal negligence is something we've taken to another level. Medicine is something you have to look for and have hope.  You could go for headache and you're dead, right? Because somewhere along the line, someone is exploiting the gaps. We know corruption is there. You spoke about corruption, you spoke about the negligence and most people were even good at running away. We're talking about people living in the country. A lot of Nigerians are living in a country that are going abroad. Canada has benefited immensely from our healthcare, our doctors. Saudi Arabia has also benefited. And the Minister of Labour said it's okay for doctors to live because there is still enough here for us, but that's not the way to process this. To lose your talent, to lose talented people, whether they are doctors or not, is to have a brain drain. And the quality of development of every economy is dependent on the quality of the minds that is driving the economy. If you lose the best talent, regardless of where we're going, it's a global world and the competition is global. You would have to suffer for it. So we have to make medicine attractive. We have to treat our doctors right. I'm also advocating for pay review if that's what's going to take. I don't even know if reform is the word we must use. We use reform and reform has lost its meaning. But I really think there is a drastic and urgent need for us to strip it down, build it up, whatever we need to do. It needs to be done fast. We don't know who is next. But Ferdi, you know, you get the real position of a country when the country actually decides to only spend 4.16 of its entire budget on health. It has told you clearly that it is not... That's more than what they spend on renovation of their national assembly. I was going to ask what are the comparisons... Less than. Was it raining inside? Less than. And the man was complaining that it's raining because they've not... Refuse to approve that.  So I don't understand why during the democracy, we've decided to bring in the national primary health care, development agency, MPH, DCA or whatever the call themselves, to interfere in the local government's autonomy in handling primary health care. In 2019, I was around a bit and I had... I went to a primary health care center, 15 minutes from the center of Abuja. And I got there. I entered a delivery ward and I'm slim. For me, I couldn't stretch out my hand, you know, which is sad. And the only thing they had in their room was iodine and panadol extract. And this is 15 minutes from Abuja. That's the city center. And about three or four minutes drive from the train station. So, Nigeria, well, we hope this talks bring up something. Well, guys, which is next after this break? Stay with us.


And oh again, we are going to take a look at a second rtf malicious sample Now this one is heavily obfuscated. So it will take some time about 30 seconds before it's completely parsed and in the rest of the video I will cut out these dead moments And you see a very very long list more than 300,000 entries So let's filter for objects and there are no objects to be found here this time So let's use jara to see if we can find out something I'm not going to run it on hex first because I don't know if it Contains actual objects or Xcode. Let's just run the rtf jara rules on the rtf file itself So without decoding any Potential hex Okay, and we have something we have Detection for a string p fragments now p fragments that is a control word that is used in in rtf documents and There is an exploit for p fragments in The Windows rtf parser in the Microsoft rtf parser So what do we have here? So of course we have the level one the rtf document itself that contains the p fragment But then we find it here in these objects which appear to be nested This one here contains six hundred sixty-two Exit a small digits and this one six six one Exit a small digits. So let's first take a look at this one here We are just going to select it not yet decode the hex just select it and see what We can discover Yeah, okay, that here is a lot of obfuscation And here we have hex code hexadecimal code Yeah, and this here With the p fragments here and we're svsv and this thing here This looks like a typical exploit for that parsing of the p fragments control word and more Obfuscation and here we have the control words, okay So let's take a closer look at the hex code here. I forgot the number I'm going to go back here to my previous command and Ask for hex decode and here we see a URL HTTP and also here command.exe This could be Shell code and here this could be a small nopsnet 9 0 9 0 and so on nop nop nops. So it starts at position 35 So let's extract this So let's cut this at position 35 and then we want everything until the end of The data we want to dump this because we are going to Run this through the shell code emulator. So let me pipe this into shell code Not bin, not vich game And let's now use the shell code emulator Yeah, and it is indeed again shell code that is a downloader. We see URL download to fiery from this URL To this file and dot exe file and then it is executed not straight executed, but this time through command.exe and then an exit


and if you see a triangle, then it is called cutting needle. Now that cutting needle also can be of two types. Whether apex of the triangle is towards the concavity of the needle, or when the apex of the triangle is towards the convexity of the needle. Both are cutting. When the apex is towards the concavity, it is known as just a cutting needle. And when the apex is towards the convexity, then it is called a reverse cutting needle. So the question is when do we use each of them? The round body needle is used for delicate tissues. Like for example, peritoneum, mesentery, intestine, things like that. It cannot penetrate through tough tissues like skin. Operate what we may think skin is a very tough structure. It has got a thick dermis and the dermis has got a elastic tissue. So when we do it on the skin, we use the cutting needle. In the cutting, I told you there are two types, a cutting and a reverse cutting. When do we use each of them? For regular suturing, most suturing that you will be doing including normal skin everywhere, we use the cutting needle. The cutting needle goes through the skin very easily. In fact, when you get the chance in actual clinical situations, you try to use the round body needle on the skin and you have health. It will just not go through. So cutting needle is used for the skin. Then when do we use the reverse cutting? We use the reverse cutting when we put very fine succulentibular stitches like for example on the face. That's what we do. So what we won't be using, so here most of us will be using cutting needle. So these are a few basic points about needles. Next about suture material. A few quick things about suture material. This is nylon. It can also be if it's black, it's nylon. If it is blue, it is proline, polyproline. Both are synthetic material. Both are non-absorbable. The big classification of suture materials, you can have absorbable suture materials, non-absorbable suture materials. The absorbable ones which get absorbed on their own, they are used for tissues inside. You don't have to remove them. Non-absorbable ones which are put in the skin, so we have to remove them after 5 days, 7 days, 10 days depending on the requirement. Again among these, they are subdivided further into synthetic and natural. So these are all synthetic non-absorbable material. That's the one which we'll be using. The whole classification is there. This range is both for them. So this is a non-absorbable synthetic. And if you notice, if you just run your hand across it, you'll find that it is very smooth. This is known as a monofilament material. That again reduces the trauma to the shoes. There are certain types like for example here, braided, where is it? There are some material like for example polyester fiber. They are ethibol. These are twisted filaments. They are called braided. They are not monofilament, they are multi-filament. They are again more traumatic, but then we use them in separate situations. Most miscarriage range we will be using. Monofilament, non-absorbable synthetic suture material, which is already swaged to the needle. So these are the few basic characteristics about the needle and suture material. Now let's take a few basic aspects. The needle holder. As it implies it is meant to hold the needle. Parts of a needle holder. These are the jaws of the needle holder. This is the fulcrum. The box type joint. This is the stem of the needle holder. The ratchet. The ratchet has got three clicks depending on how much pressure you want to apply. One. And with just a little bit of finger twist you can remove it. It just comes out on its own very quickly. You will find that in the actual instrument set you will find there will be a lot of difficulty in defining the difference between a needle holder and a hemostat. They all look very safe. At first glance they look very similar. The difference is a hemostat, the jaws will be very long. The joint will be very close to the handle. That's the difference. Why here we have these jaws very close and the jaws very small to get a good mechanical advantage so that you can get a good grip on the needle. The technique of holding the needle holder. There are two ways of doing it. One technique is as I've shown here. The ring finger will go through this. The lower one. The thumb will go through that one. Only the tips of the digits will go. Not like this. This is a very wrong method. You do not get good control. The best way to get control is the middle finger will give support and the index finger will give control. This is one way of doing it. Another way of doing it both are equally correct. It all depends on the preference of the surgeon is to hold it like this. After you have of course ratcheted it, hold it like this. In the palm of your hand and use the index finger for control. I personally prefer this. Many people prefer this. Both are shown there in the picture. Now comes the next point. How to hold the needle in the needle holder. Very important. Most of us are right handed. Therefore, the apex of the needle should be pointing towards your left. Because I'm going to go like this and I'm going to hold the needle right with the tip of my needle holder. Usually two clicks are sufficient. The long axis of the needle and the long axis of the needle holders should be exactly at right angles to each other. It should not be angulated like this or like this. They are used in very special situations. They are not used only for measuring the depth and things like that. For 99% of the time it should be at right angles. It should not be reversed. It should not be like this. Because we are all right handed people. If you are left handed, then of course otherwise it's. How much pressure to apply? If you apply too much pressure, as you can see in the picture, this picture shows, if I give too much pressure or the needle holder is too big for the needle, when I apply pressure, it tends to straighten out the needle. That's not good. On the other hand, or if the needle holder is too small, then the needle will do this and you will see it. It will wobble. When you are trying to take a bite, it will go this way or that way. So, right pressure writes as the needle for the needle holder. Usually two clicks are sufficient. Where to hold? There are three places to hold. One is either at the junction of the media two-thirds and natural one-third. Another is to hold in the middle. Another is to hold it at the junction of the media one-third and natural two-thirds. You will see different different situations. To give you a quick rule of thumb, if I want to take a deep bite of a tissue, a big needle and a deep bite, then I will naturally hold it very far away. So that I can take a good deep bite. Remember, this is the bite width and this is the bite depth. On the other hand, there are certain situations where I can take a deep bite of a tissue. I am going to do it also in certain situations. I am going to take just a bit of this and I will take it very close. Obviously, when you want to take only a bit of this, you hold it so far away, it doesn't make sense. So, these are some of the setting points about needle and needle holders. All these things are shown there. So, just to demonstrate to you, a little in the middle, after clamping it, this is how I am going to do this. You can use your own technique. I get very good control, 100% control like this. Okay, next instrument, the forceps. These are called thumb forceps, because simple reason, we are holding it between thumb and index finger. This is the next important accessory which we have to use for using for suturing. Let's take the most important one which we need for the skin. You can see the tip here. This has got two projections, the lower one and one projection. This is called the toothed thumb forceps. This is ideal for holding tough structures like the skin. I told you already, skin is a tough structure. When you hold it like this, the tooth, they mesh into each other and therefore you get a good grip of the tissue. They are used for holding tough structures like the skin, linealba and such places. When do we use the plain thumb forceps? If you know the plain thumb forceps, it does not have any teeth. Instead, it has got a few serrations on the inner surface. That's all. Just to give a little bit of friction. This is used again for delicate structures like dysentery, peritonium, interest in et cetera. Obviously, if you hold the peritonium with this moment you do it, you just cut through. You cannot use this. So for us, we are going to use the tooth thumb forceps. Method of holding the tooth thumb. It should always be, when I am doing the suturing, remember I have to hold the end which I am going to suture. So it should be at right angles to the long axis of the suturing. Not like this or like this. How to hold it? This is the absolute correct method. If you develop the right method now, then that becomes a habit. That's not the right way. It should be held like this so that you can get a good grip. That's why it is called a thumb forceps. That's about the thumb forceps. Now comes the next one. The scissors. Again, there are two types of scissors. Here we have only one. One scissor is the straight. This is the one that you see here. I am going to tell you briefly about the curved one also. The straight scissor is used always to cut non-tissue material through the threads. The straight scissor is never to be used for tissues. The straight scissor has got a pointed one, a pointed limb and a blunt one. The pointed limb is the one which goes under the loop of the thread. We should always cut with the apex, absolute tip of the scissors. Why? I will give you a practical example of what I have seen. Once the assistant was trying to cut the scissors. And he didn't realize that the tip had gone to the eye when he was switching on the base. I was watching and I could control myself.  Because he tried to cut the thread when he was switching going on here. He tried to cut like that. And the tip was going towards the eye. Never use the base. When do we use the curved scissor? Curved scissor is used for partitions. Why is it curved? Because the surgeon is the only person who cuts straight with the curved scissor. That's what you should say. See, for example, this is a laparotomy going on. We have cut the skin with a knife. Then comes the rectus sheath. Patient is lying here. Head end is here, foot end is here. As a right-handed person, you're standing on the right side of the patient. If I were to cut the rectus sheath with a straight scissor, what happens? I would have to go like this. You are not supposed to move around too much in the surgical field. This is curved. I'm going to remain standing here. So I can remain standing here and I can keep cutting like this. That's why the curves are used to cut tissues. That's why we don't have it here. A quick word about the blade. Not that you'll be using too much of it. This is a barred Parker handle. The handle is the one which is reused sterilized. And the blade is the one which is removed at this post because we cannot sterilize the blade. It is detachable. In normal situations. There are many signs of blades. 10, 11, 12, 15, 21, 20, 21, 22, 23, depending on size. This is the rice 10. And the handle, how to cut. You're not going to cut it. I'm just going to show you. Hold it like a pen. Not like a stabbing instrument. Not like a fighting instrument. Not like a pen. Because it's a delicate situation. Give control to the next finger. Angles should be 45 degrees with the skin. First 45 degrees.  Go straight down. Bring it back to 45 degrees. Give a little bit of counter traction to the skin. Otherwise it will punch. Keep proceeding in a straight line with a steady hand. As you go further and further, you'll find the skin is becoming much lower down. Bring your hand further down. Again bring your hand further down. Bring your hand further down. Bring your hand further down. Until you reach the end of the transition. So this is just a technique you're not going to do any cutting now just to complete the whole picture. So I have to demonstrate the basics of the instruments. The first suturing which I'm going to demonstrate will be the no-time technique I'll do. I'll show you where I put the suture. Then we'll come to that. This will do four suturing techniques. There are many of them written here. Or essential ones. The simple interrupted. This is the first one you'll learn. So let's do the fourth technique now. We're going to hold the needle holder. The needle with the needle holder. We'll use the thumb forces. Let's say I'm going to do a suturing here. The first one. The simple, interrupted one. It's really not very difficult at all. So like I told you, you can hold it either this way or this way. I prefer to hold it this way because I get more control. You should be able to hear the clicks and see how much pressure you've applied. Now it's stable. No red notes. Not everything. Watch. So suppose I'm doing the suturing. With the tooth forces. Hold one end of the place where you want to put the suture. Here for your guidance, they have already put dots here. In an actual situation, you will not have these dots. So we have to determine approximately half a centimeter so take a good grip of the skin. It's a good grip so that you can lift it up. Take the first bite through both thickness with a slight curving motion so that, as you can see in the lower picture, less of the epidermis and more of the dermis is taken because we want the edges to be slightly diverted. Inversion is not a good thing. Iversion is required. Good healing. Epidermis to dermis. Epidermis and dermis to dermis. And it reduces the good health and so on. So that's why we have curbed needles. Of course we do use straight needles for various situations but here curbs them. So a slight more of the epidermis, a little less of the dermis. Full thickness. If you find difficulty, you can take it out and you can take the next one. Or you can do it both in one shot. It doesn't matter. It depends on how big the needle is and how deep the suture on the skin is. I've just removed it. So one bite. Next bite. Again take a good grip on the opposite side. Give a slight push and you can see the tip of the needle pushing. So I know approximately this is the place I want to come out. Once you release it, catch hold of the tip and pull it out with a curving motion. Keep pulling until you reach the approximate reasonable side. Don't keep this too long because remember you'll be cutting it off. This will be a waste. We have to conserve material. At least if you don't, your assistant is going to jump at you. So keep it a certain length so that we can photo. Now the previous slide that I've not done technique is shown. Watch this. Another thing which I forgot to tell you about the suture material was when I was talking about is the not holding characteristics of suture materials. These monofilament materials, synthetic non-absorbable monofilament material they tend to slip. You can try it. You can take a piece of nylon and you try to make a loop.  If you take a cotton two throws or your shoelace for example, you don't put ten knots. It holds. Nylon synthetic material they tend to slip. So we have to use multiple throws otherwise they will slip. How to tie the knot? Long end two loops clockwise tip. Hold the tip. Give it sufficient pull to make it a little tight but it is not sufficiently tight yet because it will slip off. See it is already slipping out. Now with my hand like this anti-clockwise two loops again hold the tip and same direction with my hand where it came back to the left tighten it a little bit four throws I usually like to put six or eight because anything less than that tends to slip. Again two loops catch out of the tip again cross again two loops anti-clockwise catch out of the tip and once you finally made the knot eight throws give a little flip like that the knot goes away from the suture line either this side or this side never keep the knot on the suture line because it will give a very beautiful and bad scar Once this is over don't remove it keep the tension take the scissor apex below the knot cut it approximately half a centimeter away Why do we keep this much length? Two reasons. Reason number one, seven days later you have to remove it if you keep it too small you will not get a good grip to remove it I am going to show you how to cut it The second reason is as I told you they tend to slip even after putting eight throws if I keep that end very small it might slip off So I am going to do another one fast and then I am going to cut towards the knot and then you will start doing your own So this is the technique I am going to do the next one one more so that you can see it full thickness little more of the epidermis opposite side full thickness curving out double clockwise hold the tip anti-clockwise hold the tip clockwise hold the tip flip seven days later the patient comes to you you are going to remove this that slide is also there how many days later to remove the sutures most times it is seven days, sometimes it is five days sometimes it is nine days, sometimes it is ten days you take the average figure seven days, catch hold of a grip with the tooth force catch hold of the knot get a good grip not on the suture line but away from the suture line put the pointed portion under the loop cut because I have experienced it sometimes the suture line is still not fully healed when you put it this way it pops open so pull like this next one get a good grip put the pointed end under the loop away from the suture line cut with the tip full procedure is done please go back to respective stations and start over the first suturing thing