 Right, everyone. Hello. Good evening. So this is this is a talk about releasing software to the public, because obviously, you know, we're here, we all benefit from public from open source software in its various forms. And this is a very brief talk on on why you should go about doing that and what you should maybe want to keep in mind. For those of you who don't know how you create a new or rather maybe let's let's wait for that. As I said, my name is Peter. I work for a small consulting shop here that deals primarily with transportation companies. I have worked with Ruby and its various forms for about 10 years. And we mainly use it as glue code to tie different things together. And we have a couple of Rails things as well. So that's just sort of sets the sets the scene. Now, this is obviously how you make gem. You do bundle gem name of it off you go, right? So if anyone came here for the purpose of finding out how to get started on a new gem, this is how you do this, right? Good. Thank you. Have a great evening. It's been a no, this is not not not quite. Yes. It's a it's a rake task that tags and builds and uploads it to rubygems.org manually. Right. Okay. My next talk will be called what is rake? No, so so this actually this. This came about from a from a real life situation we have. We've been doing a number of mail migration projects for for some of our customers and it's a pain in the ass, but it's still something that has to be done. We needed to make sure that things were integrated correctly between old new mail systems. And so what we ended up having to do was to send a bunch of emails to a whole bunch of people and send them over and over again to make sure that everything was configured correctly. It's not particularly entertaining work, but it's obviously something that lends itself very well to automation. And what we had before was someone had written some shell script to do this. Someone else had written a rake file with some embedded ERB. It was it was it was really not pretty and it was just it was just you have a problem. You write something and off you go. So we wanted to do a rather I wanted to do something about this because it was getting a little bit it was getting a little bit annoying. Now, I don't know if any of you want to take a wild guess at what my favorite food is free food. So along the same lines. What is my favorite code code that's already written. Right. And so I know I don't know if any of you have heard of swags. It is the Swiss Army knife for SMTP and it happens to be literally the first hit on Google when you search for scriptable SMTP test tool and Linux. So if I had known this, I wouldn't have had to build this thing because it essentially does everything we wanted to do. And so it's a flexible scriptable transaction rather SMTP tool. It's it's neat if you need to do any any any email testing of any kind. So that leads me to my first point. One of several rules of releasing open source software. Google it because there's a high probability that it's already something out there that you can use and you don't end up wasting time like like I did. We have some requirements for this for this particular thing. Like I said, we had to send all these emails. So we had to be able to stick in a random long work. It just had to be random and relative and had to be unique because it allows us to find stuff easily afterwards. We need to have a sequence number. So if we're sending out 250 emails, we need to know it's number 216 that didn't show up to that indicates there's something wrong somewhere with that. We had to show progress. We had to provide it a list of email address. We needed a way to replace the domain so that we can send one thing to one group of people and then send it to the same group of people but on a different domain. And we need to be able to specify relay host and port and that was that was really it. So this happened on a Sunday. And I, you know, we all fiddle around with code. We have this code that just sort of never gets into any kind of releaseable state is just code that does stuff. So I thought, okay, let's try one thing. I want to make a rule. I am going to release to the world the glorious version 0.0.1 in one hour. So that's the time that's available. And it has to be releasable in an hour. And that's it. So those are the rules just to keep it simple. So my CSS skills aren't the best, which is why you will notice that this thing is sort of pushed towards the right. It's somewhere between org mode reveal.js that this is happening. But anyway, so this is the outcome of that thing. The gem is called mail test. And you specify a bunch of parameters and it sends out a whole bunch of emails. In this case, two. And this is quite ironic. So this is a graphics. This is a PNG screenshot of a text email inside mud inside a terminal anyway. So the mail went out. So this thing actually works. And as you can see from the git stats here, there was one commit that was done at 4pm on a Sunday. And that was the first version. It took about 45 minutes. So what is it then that has been written? Well, here is some of the output from RuboCop. Simon Brandt's condition size is too high, too many lines, too many lines, too many lines. So that's what you get for about 45 minutes worth of work. It's not necessarily pretty. It's not so bad. And you also get something like the use of eval is a serious security risk. And this is really like the point of the why I'm here, because I'm going to show you what I wrote. And I wrote this. I decided to badly implement an extract params method that takes a hash and uses eval to set some instance variables. And I don't know why. I don't know why it was written that way. It was just, you know, I have this one hour. I need to get this done. If I can write this and make it public to the world, it doesn't matter what code you have that you are embarrassed to release. Just get it out there. It cannot be worse than this. I promise you that leads me to the next rules of releasing open source software. First of all, same one as before, Google it. You will write code so ugly not even a mother could love it. But you know, it's okay because in all likelihood, nobody's going to read it. Maybe not your code, but nobody actually reads my code. So that's from the repository. Right. I think there's a point more I want to make. All right. So tests, right? 45 minutes. How many tests can you manage to squeeze in? There's one. Test that it has a version number. Well, at least it passes. It's the default test that you get when you get started, right? With, I think, many tests in this case. For some reason, I thought it would be a great idea in the, this is the rakefile, subsequently, to start accommodating both regular tests and benchmarks, just in case I ever wanted to benchmark this thing. And this really leads me to another point. How much time was spent on this? Well, first of all, I'm guessing a bunch of hours on some of those earlier shell scripts and early ugly rakefiles. Then there was a few hours that were wasted on, this is a really annoying way of going about doing it. Then there was one hour spent actually building something that solved a particular need. And then about three hours afterwards of sort of trying to clean things up. And, you know, it's not that it's not one set of three hours, but it's sort of coming back to it a few times. And it's the context switch and you're working on something else and all that, right? So you end up with, I don't know, a good 10 hours worth of time of your life that could be spent on something productive. Whereas in actual fact, it was really that just that one hour and problem was solved. This code is never going to be touched again. By now it's version 0.0.4. But no one will ever touch it again. It does what it needs to do. And I don't know about you guys, but I think it's in this particular area we have chosen to work in. There's a tendency to say, well, I want to make this nice. I want to make this good. And other people are going to see it. And what if I'm going to be making changes further down the line? Or what if I might also be wanting to do something else? Guys, don't do it. I mean, it's probably not worth it. So Google it. It will be ugly, or at least mine is ugly. Nobody will read your code. And as they say, perfect is the enemy of good. And I don't in any way mean that this is perfect. It's sort of more metaphorically speaking, right? We can waste a lot of time trying to optimize something that really doesn't need it. So if any of you can do me a favor, and I know that at least I see some faces here with some people who have released something that's used by thousands of people, so that doesn't, Nick, this isn't meant for you. But if you have some code at home that you've used for something that serves a purpose, just release it. It really can't be worse than my evil crap from earlier. Just bring it out there someone might use it. Right. You're very welcome to get in touch if you want to. This is how you can do that. Any questions? Oh, great. Thank you. Yes. Since you have demonstrated great release to me, and I was telling you, you could just set instance bar. Yes. But so in the version 0.0.4, actually that's what I did. I really wrote it to that. And then I thought, okay, this is ridiculous. Why am I even fiddling around with this? So that code is all gone, if anyone would want to check out the 0.0.4, which is a marvel of engineering. Any questions? I wonder if there are some disadvantages of releasing the code that you actually don't like. So I'm thinking maybe, just potentially, you apply for some job and someone goes through your hip-hop account and they see this crap code and it makes a negative impression. It's even worse than most of the code that you work on is a proprietary code. So your hip-hop is full of like, you know, some forks and this is the only record that you give, and it's just a crap code. So then it doesn't make a good impression. So I wonder if you can add some other ideas why you're even actually releasing the code. So that's a different, I think there's a few different things in this. Well, first of all, you can of course just say, well, this is just for internal use. No one's going to be using it. I don't think anyone is going to be using my mail test, Jim, for anything. But for me, it was more a case of making a sort of a hard line in the sand and say, well, this is the target, right? This is what I'm going to do here, because otherwise I could just be fiddling around with this thing for no gain whatsoever. But yeah, I know that supposedly the recruiters go around and check out people's GitHub repositories and stuff and look through this. If I was assessing someone and I went to look at their stuff, I mean, obviously I would do that too. I think that I would probably be able to distinguish between some throwaway shitty piece of junk that was just made for one purpose and then something you're actually proud of. So, you know, each to their own. Yes? Yeah, I just want to thank you for the talk and encourage everybody. I did exactly the same thing at some point and just thought like I never released the gen before and I didn't have anything good in that time to release. So I just, I don't even remember what exactly I did. Just wanted to ask you, like, when I did this first time or first couple of times, I had the same issues again and again, like, do I commit gen quite a lot or do I don't commit gen quite a lot? Do I include my development dependencies like ours back, for example, or do I not? How do I do worship, et cetera? Maybe you can share your experience on a more low level. Thanks for being here. Okay. So regarding versioning, you start at one and then you just increment. Well, that's the whole thing of semantic versioning that I'm sure everybody or at least most people would probably be familiar with, which is one way of going about doing it. And if you're wondering how to text off, that might be the approach. I, in this particular case, I literally just incremented one each time. And, but otherwise, when you do, when you do a bundle gem, it actually provides you a fairly nice game framework, including a good ignore for all this stuff. So for something, right? So I guess there was no breaking changes because we haven't changed. No, no, there were no breaking changes. There was a lot of breakage. That one. All right. Thank you guys.