In this episode we discussed something we deal with occasionally - understanding a problem or a pain, thinking of a solution, and then implementing this as a tool or a product. We share some tips that can help out when starting to build, both from the engineering side but also from Ops perspective.
Links
Meir's blog: https://meirg.co.il
Omer's blog: https://omerxx.com
Telegram channel: https://t.me/espressops
In this episode we discussed something we deal with occasionally - understanding a problem or a pain, thinking of a solution, and then implementing this as a tool or a product. We share some tips that can help out when starting to build, both from the engineering side but also from Ops perspective.
Links
Meir's blog: https://meirg.co.il
Omer's blog: https://omerxx.com
Telegram channel: https://t.me/espressops
shasammeledi! Letian Excited because we don't know how to do it so We're going to figure it out So, Omeira, are you ready for the first question? I think so. I think so. So what's the first thing that comes up to your mind when I say, Omeira, how do you start a project? Like you have an idea and now you want to do it. What do you do? What's the process? Okay, let's narrow down when we start a project. So the first things, just the first. Yeah, sure, but when we talk about the project, like a tool that we have in mind, I assume, right? Something that we need to create out of thin air, there's something that I want to be done by a system, not by me, and I want to create the process, I'm guessing. Yeah, even like maybe an example, like maybe a left-week open TF, decided to be a thing. And let's say you want to be the next open TF. Let's say you heard about Terraform and you're saying, I want to create an open source, which, I don't know, drags, like an get support from the community, and take it forward and whatever. So how do you even start? Okay, so the first thing comes up to your mind when I say that. So I wanted that bombastic. I don't think I'll create an extra form or something like that, but I do have tons of ideas, and I'm actually working on one right now. But you asked what's the first thing that comes to my mind? And actually, the first thing that comes to my mind is not how to start, is how to finish. And what I want to say by that is if you create a tool, just create it. And if that means that the first thing you're going to do is making it relisible and put it in a repository or provide a download link or something that people can install that, and then go back to playing with the rest of the stuff. And I'm saying that because I've started, I think, over 20 or 30 different projects, and maybe one or two of them saw the light of day. All of them just ended up in the graveyard of tools that I have thrown in my GitHub, either public or not public, but are not being used by anyone, including me. And there are great tools, I think, great ideas. One of them I'm working on right now. So maybe this is my chance. And I'm saying, I need to relist this thing. So let's focus. OK, OK. So let's start, since we don't have any pre-questions, like we don't even put a pill. So let's see, I like the direction you took. So what is your suggestion to make tools not reaching out to the graveyard? So what's your suggestion of what you said now? But let's focus on that. Like, how would you encourage yourself to actually do something with the project and not just say, man, it's not going to happen, and then just ditch it and, you know, an archive that I've posted to it? I think we're turning this into a psychology discussion where you are the therapist, and I'm on the session, because what I want to say is, OK, I have a problem. And there's a saying, done, bit's perfect, right? Finish something. It doesn't have to be perfect. Shape it, deliver, and then start tweaking it. And I think that's my problem. For example, I'm building something now. And there's something I'm building. I didn't want it to be CLI. Like, I always build CLI, because I'm used to work with CLI. I wanted to build a TUI, right? A terminal user interface. There's a very nice project, a set of projects on GitHub by a company called Charm. And they give you the ability with open source tools to create your own terminal user interface. And it's really nice. I mean, you get this colorful UI with buttons and progress bars and text areas and things you can actually play with. So you're in the terminal, but you get the feeling of web interface, right? I wanted to build that. Do you know how much time I spent just on creating the border? Oh, I think three days. And at some point, I told myself, god damn it. If I keep working on that border and tweaking with the colors and fixing the way I want it to be tabs, right? I wanted to have three tabs that you can move around. And then the menu changes. If I'm going to keep doing that, it will never go out. So I think the first thing, implement the logic, make it work, make it do what you want. I wanted to do a very simple thing. I can talk about this project specifically. But it has two different features. They are logging into AWS. One of them is a list that you can pick from your local profiles. The other is giving you all of the accounts that you can access. And let you set the keys in your AWS config. That is it. I was doing none of that, okay? So that's why I'm going to the end. First, make it deliverable, releaseable, prepare the project, the structure, everything, implement the logic, make it work, and they're start tweaking with the rest. Make it work to a point that you can give it to your friends, right? Hi, I have a tool. If you want to test it, give them the link, give them something that they can install, and then start working on the other parts. But then I'm going to ask like the scariest question, like that you ask yourself before you send it to a friend, is, but if I send something that is not good to a friend, he's going to check it. He's going to say, this is not good, this is not good, this is not good. I will tell him, yeah, I know. It's working progress, but focus on the main things. He will be agitated and he will be irritated and he won't really want to test it because it's like every time I tell him, yes, yes, it's in progress. But focus on this focus on that. So then my friend will give up. He won't give me feedback anymore. And that's like that's like the scariest scenario that people actually experience, you know, you tell people, you get your friends high, try it out. They give you feedback, but it's not a real feedback because it's not a real product. And then you're in this magical circle of how am I going to finish this project? A vicious cycle, yes, you're right. I mean, what you said is perfectly right. And that is one of the points. And I actually did that. I actually built something in three hours and sent it to one of our group leaders and told them, can you check this? I built something that might help you. And here I am looking for a job. Yeah, kind of. But he was, I mean, immediately he sent me like this screenshot of, I got an exception over doing nothing because he had nothing in his list, right, I built it. So what I'm saying, you're right. So first of all, I'm still standing behind my words, do make it relisible, but I think that if I'm building something, make it good enough. So you know, we have all those MVP, POC, whatever you want to call it, just make it good enough. But have it delivered with type ends. If you're running, for example, he's a new user, right? He has nothing configured, a new user for AWS, for example. I'm working with something that configures your machine to work with AWS. Don't assume you're the only user. I'm talking to myself now. Don't assume that owner is the only user. Maybe there are new users. No, maybe there are going to be new users with that have nothing configured yet. And you want to support them too. So we're going into like building a startup, who's your persona, who's your, you know, you have a product, you want to have a product market fit. Not going all the way there. It's just a tool, but do think about who's going to use it. So I needed to think about different people that are going to use my tool and you're perfectly right. Make it good enough so that they can enjoy and get a value from your tool. At the end of the day, my tool is very simple. It's configuring my local environment to work with AWS and having me authenticate with SSO. I already have the code, it's working. The logic is working. Just have it not break in the first friend through someone who tries to use it. You know, bring value. And then after you're bringing value, even if it works like shit, it looks very bad, but it works. It does the job. At the end of the day, I mean, I'm writing a local script that helped me with something. There's so many tools that I just do that are just even basket. And they work, they do their job. They're not the most beautiful things in the world. I could probably improve them, but they do the work and they help me. They end they out. So that's what I'm saying. Deliver something that works and brings value and won't break. Okay, so let's, all right. So let's try and move on. Okay, so I asked Chaji P.P. Of course, Model 4. How would he start a project, all right? So I want to go through the bullets that he wrote. And I want to tweak them a bit with you. So it's like I want to take the list that I got and maybe play around with it until we have this perfect module of how to start a project in the right way. Because right now at Bot told me how to do it, I don't think the bot is right because like we're in the day life and usually the bot says the, the best scenario that is like when everything goes well. So we'll probably need to tweak it a bit. Let's talk about it. Okay, so first the bot says like Chaji P.P. says, requirements gathering. Okay, so define features and functionalities. You want your app to have. Okay. I would start with something different completely. First, I would look for references to see if my idea may be a lot of the exist. So even if I want to write an open source tool and I don't know, maybe I should first find out. Maybe I want to write down, I don't know, the new Terraform. Maybe I should look for open TF, you know, the new open source and contributes to that instead of opening my own new Terraform. You know, so my first thing that I would go to when I like to start a new project is look for references. Look for something that exists out there. Anything you want to add about that, talk about that, like how would you look for references? What would you look into them? I mean, yes, but this goes to the funny part of the conversation because we're both engineers and I think 50% of the projects we start are just because we like to build, right? Think most of the times I'm building something that probably exists in one way or another out there. If you look well enough in GitHub, you'll find anything for everything you're looking for. Maybe not in the exact language you like, maybe not in the exact form you like. So I do agree with you. I do try to look for references and usually, I mean, when you're building something, it's out of a requirement, out of a need. I think the process you ask your Japanese after, it's assuming that you've already found yourself with a problem, you don't have a solution. Maybe you Google it search in GitHub or something along those lines, you didn't find a solution, you're building one, right? I guess that's the starting point. So maybe, so maybe it doesn't really know. So regarding what it said, like the requirements gathering, like say the functionality, it's something that you said, I think in the start of our conversation, the beginning of the conversation that first try out and realize what you want your product to do. What's the value? What's the value to release it? Yes, what's the value? Okay, MVP just for those who don't know, many more valuable product or anything else or only many more valuable value of value, I don't know. Yeah, basically, maybe move something you can deliver. Yeah, reaching a line that you can deliver and provide the value to, I mean, to someone. Okay, now, now, judges said something that I absolutely do not agree with. Okay, the second point is technology stack, front end, back end, and maybe epoxy, whatever. So it talks with me about which technologies I should use. Right. And I think maybe, and I think you will agree with me, that will be probably my least concern. So at first, like in my end, I would first like realize, what do I business, like business wise I need to do, realize my audience, realize like how I want to serve my application, if I want to be a terminal UI, if I want to be web based, how many developers I have. So this is an old thing on it? Yes. So it doesn't have to be like, technology is a lot of things. Technology doesn't have to be, I'm going to use JavaScript or I'm going to use this or that framework for my project. That's what JPG wrote. So I think he's kind of, yeah, but at the end of the day, JPG, but I think it is still valid to understand the technology in the sense that what environment are you going to run in, right? Is it a web protocol, it's not a protocol, maybe it's a web application, maybe it's a terminal application, could it be just a CLI or a bot that's running in a social media, like a chat bot or something. So I think the environment makes difference in what you build, but then again, you can connect that to everything later on. So that's the only thing about technology. It just sounds like a beginner's advice to tell you this and before you start something, choose your technology stack. And I'm thinking that my technology stack when I started project would probably be the last thing. Okay, unless I know only one language. So let's say all I know is Python. Obviously, I can start talking about my technology stack in which packages I'm going to use. It's that's the only technology that I know. But since like we're DevOps engineers and hopefully our crowd is also like they know more than one language. So if you don't also know TypeScript, Java script, Python, go long, bash, whatever. So and also in the cloud, you got so many services for queues, rabbit and queue, this queue, AWS SQS queue. So if I want to implement a queue, I wouldn't go and select like which queue I want to do now or even I wouldn't even talk about the queue. I wouldn't know that technology only after I have a business plan like a business functionality. Like after I know what should happen, which component should talk with which component and only then I would select the technology, you know. So that's like the last thing I would do. I agree. However, there is a connection. Let's say that we decided that our environment to begin with is like what I'm building now and it's going to be in the terminal because it's obvious oriented and people who use it are engineers that work daily with AWS and that's what I want it to be. I mean, I'm trying to prevent them from using the browser because I want to bring them something closer to their fingers, right, air quotes. So if I'm building a terminal tool, I will probably write it in one of a few languages and not other languages. For example, JavaScript is great for that. Go link is great for that. Obviously, Rust is great for that. And what I'm saying is two things. One of them is how easy it is to find the framework to build your CLI. If you're writing Go and you already have Cobra or you're writing JavaScript and there are tons of frameworks for that, obviously with Rust, obviously with other similar languages like Python and Ruby, that's easy, right? If you go with a niche language like Crystal, I love Crystal, it might be maybe today not, but three years back, four years back, it was hard to find frameworks for everything. And even if you do find a framework specifically for the CLI, maybe you don't have a framework for a role working with Redis or a specific database that you want. So I do think it's important to understand the environment and then from that kind of understanding where you're going to, in the sense of, you know, a language and frameworks and everything around that, that's the first point. The second point is you're building an open source. I'm assuming, right? We're talking in the context of open source. And the idea of open source is not only showing your code it's getting contributions from the community. And if you want to be able to get contributions, it's important to think about the language that you're going with in regards to where you're getting. But shouldn't be like step two or three of what you're of your project. That's what I'm saying. Like I don't think it's not important. Don't get me wrong. It's super important to choose also the high technology selective on if you want to migrate. It will also be easier. But I wouldn't take it as the first, second, or third step, maybe fourth. Like we'll see what else in the list, but it's right. It's right, but I'm bringing you back to the world. I think you're aiming to building a full-on plan to something that you're going to build as opposed to an engineer thinking, oh, I have a problem. Let's write a script to fix that. And maybe let's not make it a script, make it something a little bit bigger. Write is a tool as an actual binary that I can release. And what we're talking about these steps are happening in the span of five minutes, right? There's a problem I want to solve it. After five minutes, I'm already googling or searching in GitHub for specific goal-length frameworks to build what I want to build. I kind of already, my brain already works in a way that the cog wheels are turning and already picking technologies as I'm understanding the problem. So yes, you're right, if we were all really organized and would kind of lay out the discipline to everything we build, it would work perfectly. It's just nine of the 10 times. It's probably not the case. That's what I'm saying. OK, so I'll give an example of a tool that I created and open source one. It doesn't have like, it's not like it's a successful tool. But I think it's a good idea of a very, very, very small tool and how I started doing it. How do you measure success, may I? Are you happy about it? And I mean, I measure success of how I use it. So I don't use it as often as I thought I would. I don't even care about the audience. I'm like, I'm using it like, seldomly, you know? I use it like not often at all, like, OK. So we'll talk about it in a few minutes. I just want to move on to the next bullet that Chad J. PT said. So also I think it's related to technology stack, but it says set up development environment. So it's modulated to what you said of just start working, you know? So set up development environment. And then the fourth. So development environment at technology stack are related in my opinion. So we can skip that for now, because if you choose technology, you can set up the environment. But then it says, OK, then it says design system architecture. OK. Plan how your server will interact with API requests, blah, blah. Now I'm thinking, this is something I love to vision. Like, again, it depends on the system. So if it's a simple CLI, I won't probably need a very complicated design. But when I'm building a web server or something that requires, you know, communication between microservices, usually I do want to have a very, very simple and short sketch, nothing, draw a yaw or diagrams or or anything that will kill me, because usually what happens, you start running in them. Then it's not very aligned, because as you said, the terminal UI, like all the font and stuff, when it's not aligned, it's driving that's crazy, right? And it's not perfect. But if, but you are more forgiving to yourself, if you take a paper and you start writing down on paper, and if it's not that aligned, you're good with that. That's like, that's OK. So I just take a paper and I draw like, OK, so this is myself. Like, you know, people do on the board, draw it. And then I'm like, OK, I think it makes sense. This sense communication to this. This will be like that. OK, it looks good. All right, I can start. So this is usually the first thing that I do. OK, so see here. Chagivity said the system architecture comes like after technology stack. Any opinions about that? Yes, I think it's not organized. I think it's not the order. Obviously, as you said, the one tip I have, maybe again, it could be totally personal. The one thing that you can have always accessible that really, really, really helps with everything is a whiteboard. Not fancy tool. I do have fancy tools I use, but whiteboard is everything. I mean, it allows me to spend on those tools where you need to align. The hours I spent on Excalidro are beyond reasonable number. Any reasonable number. I thought it was a therapy. Do you know the thing? So you start working with those tools, with those sketching tools. And during that time, that's how you create three subnets. And then you realize that the tool allows you to use valuable. So then you're like, OK, so I'm a creative valuable. So instead of writing and working on your idea, which is what you want to do. I want to start with subnets to look better. But the database, I don't like the way the barrel is shaped. Maybe I'll add more lines. And then, oh, maybe it's also Postgres and SQL. I need to add the logos here. Nobody's ever going to look at your wonderful chart. Exactly. So this is why it's so funny that you're working on the shelves instead of working on your tool. But if you sketch it on PayPal, maybe not even on a whiteboard, because it sounds intimidating. And not everyone has a whiteboard in their house. But a pen and a PayPal, maybe people have it in their house. Also today, it's not that common. But one way or the other, it's very important to have a sketch to anything you build. If you don't, you will pretty quickly figure out why was it important to have a sketch, because it's hard to keep all the details that you had in mind. And obviously, it's more complicated. It's just one script that does one thing. If you're building, I built a Telegram bot. There are a lot of menus and different options. And an admin menu and the way you treat your users and roles and whatever. It's hard to keep it all in your brain, at least for me. If you have it aligned or laid out in something that you can map, that's really easy. Pen and paper is great. Whiteboard is great. However, there is this notion of mind maps, those. So mind map is kind of a way to just throw things and connect lines between what is connected to what. And you can have hierarchy. I mean, this is like the parent and those are the children. And you can easily, if you just look for online mind maps, you'll find tons of them. But it allows you to lay out a lot of information and make it like in a some order. That's easy to find. And again, with the hierarchy, parents, grandparents, all the way to children. And it allows you most of them to zoom in and out quickly. You can have a huge chart. And it's all laid out in a flat manner. You don't have to click anything to go to the next thing. It's all there. And you can zoom in all the way down to the children and zoom out to parents and zoom out all the way to the root. So in some cases, this is really, really helpful, especially when I'm building something that has a lot of different menus and trees with branches that I need to create different areas in a program. This is, by the way, what I just described is kind of a CLI. If you have a CLI with sub menus and different flags, but flags can be global flags or just specific flags to a specific menu, that's really easy to describe in a mind map. That's usually what I do. And I also want to emphasize why it's important that to sketch, because if I want to share my tool with you all now, because I want to get your opinion as a friend, open source. It's free. It's open. Everyone can join and help. And if the best way I think to explain something to someone is to visualize it. So if I just talk with you about it and see you talked about the terminal UI, but no one knows how it's going to look like, right? We don't really know me and the audience. Don't really know what you mean by that. But if you just had a sketch, a very short sketch of what's your vision, like, so that would help me to understand what you want to do, what you want to achieve. Also, when it comes to the architecture, with the tools, with the communication between tools and everything. So in the sketch, I think the best tip I could give is think of the flow of the flow of the client. So what's the first thing that your customer or your user is going to do until the point they get a response. Remember how we always talk about the self-congregation and what's going on with that? So I'd go through this, like, my client clicked this, then what goes all the way until the backend and behind the scenes and whatever and all the business logic until they get the response and walk from there. So that's my tip. And it keeps all the sketch on it. Kind, I want to touch two points you said. You talked about sharing and you talked about letting your user kind of getting a visual into what they're seeing, right? So you talked about the sketching, I think, should be for you, mainly that either the developer or the owner of the project and for future contributors. However, if you're sharing with a friend and I'll talk about the sharing point in a few moments, if you're sharing with a friend, I think the best way to give them kind of a visual, like visually understand what you're building and what you're seeing there is to give them something visual, right? A video or some type of media. Now, I find myself the second time promoting charm here, but the same charm suite of tools that I'm using to build my current terminally wide. They have a tool that's called VHS. And VHS is basically kind of the old VHS video recording. It's a tool that records your screen. It records your terminal in the different, you know, you can operate the UI, you can start moving between different menus, you can run certain features and it records it. And then when you're done, it records it to something it calls a tape, like a dot tape and then you can turn that into a GIF and that GIF is ready to put in your readme of the project. So that's really easy and then you kind of put a GIF with your running through the menus, running through the tool, explaining without, you know, without any audio explanations, it's just very understandable from you operating the UI, what's going on. So that's about the end. I use it for that, do you know, GIF-y? Yeah, of course. Of course. Their way is just tailor-made to use your terminal UI and record that specifically. It's very nice for that. So this is this and the second thing you talked about sharing and specifically I want to touch the sharing on your building something, whatever language you're building. You want to share it with people. If you're writing a best script, that's rather easy. You copy the best script, you put it locally, you run it. Although that's not the best way in the world, you probably want to provide some way of installing it, right? People like to install stuff. So what I'm saying by that is put it in some kind of a repository, my prefer, I'm working on Max. Mainly, I'm assuming my users, most of them will work on Max. So I will first think, go to Homebrew and I will put that, whatever I'm building, I'll create a Homebrew repository in my GitHub. That's very easy to do, a Homebrew tab, they call it. So you're going to install your private tab and then under that tab, you can put whatever tool you want and then you can run a brewing stall, or whatever my handle is, slash name of the tool. That's it. You can install it. You give me a better alternative that you have in your head because I know you do a better alternative so it will support both windows and Mac OS. There, tons of them. What, just one, just one, I want you to say just one. What, a repository that supports both? No, I mean, yeah, I want you to be able to share your project with Windows, Linux, Mac OS. Okay, so how would you wrap your project? So what I wanted to say before, I don't know what you're talking about in terms of delivery, but I am building a matrix of releases to every possible architecture that can be Windows based, Linux, obviously, Macs and different architectures to any kind of possible architecture you're going to run and one name, these, whatever. I just wanted you to say, so you can also Dockerize. You can also containerize the application. That's it. Just wrap it with a container, with a Docker image and ship it to your friend so that they can run it locally. My comment is, for that is I usually try to provide it if it makes sense to provide a way to run it within a container, however, that will only be like a side note in my reading. I don't, because you're running Docker, that essentially, if that's the easiest method you provide, you're kind of forcing someone to use a lot of more resources and what they already are using, right? Because that forces you, I'm running Docker all the time. I don't have the Docker demon powered on all the time. And I don't want to keep it running in the background for me to run some kind of a niche tool, right? So that's an option. I will provide a way to run it with Docker. I don't think that should be the first or the second one in the list. It's just an option to someone. News flash about Docker. Yeah, they have a power saving mode. So if you don't run anything, you can have the demon running in the background and then you have a leaf on it. I don't know if you know, you notice. If you update Docker demon, you'll see a leaf on it. So it's now in power saving mode. Just so you know, it's a new challenge. Ten seconds round. Ten seconds round. Yes, yeah. I know about their new mode. I have suffered so much from Docker running in my background, killing every possible lift resource left whatsoever in my machine without even running a single container. So I'm not believing them anymore. And it's always down, unless I'm running a container locally and I need it right now, it's always, always, always down. So to give you an example with Docker that I like, a few episodes ago, maybe like 10 episodes ago, I talked about that I wrote a tool, bugs, a member of passing bash arguments. So my example, like I created a Docker image, pushed it to Docker Hub. So if you want to run bugs and use my example, especially if it's in bash, so I just wrapped my script with a Docker image. And then you can Docker run bugs example and then test it locally without installing anything. So this is why I like Docker, you know, the fact that you can really just run it, you know, without dealing with anything else. Totally, just to better test it. I'm talking like just to for the initial impression. If you're talking about, but I want it to be implemented as part of my daily work and blah, blah. So of course, containers are not good to be used as CLIs. I don't use AWS CLI as a container. Some people do, maybe. I mean, you can. Of course, you can. You can. Unnecessary, I agree. I will tell. It's even quite standard tools. It's even quite standard. I do see it in a lot of, you know, mega projects on GitHub. They do provide the functionality. They do have the option to run it as a container. I don't know that people like it. Not me. So yeah, so I think it's easier. If you just want to test it without being committed to because you're saying Boeing stall, to me, Boeing stall is something heavy because also has this blue update before Boeing stall and I did not disable it. Yeah. And I don't like, it's like, you know, Python if you do peeping stall, then it's like, okay, maybe it will store another requirements. So yeah, bro, just decides to upgrade your entire system with one line. Like, I think Docker is like, if you really want someone to adopt something fast, so providing a Docker image, like not even a Docker file because then you, your users are committed to build your image and you don't want that. So just provide a Docker image, a short, you know, short snippet of how to run the application, then it's way easier to adopt it or just test it before you're committed to installing it. Yeah, I agree. My point was provide something. And that's something, I mean, obviously it's easy to just release a matrix of binaries. I have a tool that called go release or it's very famous. It runs across whatever you tell it to run and it releases anything you tell it to release. However, if you're just providing a binary, it's hard to go take the bind. It's not hard, right? But you now need to decide. I will install that binary and I'll put it in my, where in my CMD share user, whatever you need to start picking. If just provide a way to install, it makes it much more easier for everyone. I'll give you an example this morning. I just upgraded my T-Max configuration and I'm running T-Max's and multiplexer from my terminal. And I wanted the plugin that allows you to kind of copy paste with the VIM shortcut or not VIM, whatever. You can just copy paste from your terminal without the mouse. And you need a plugin for that. And the plugin, it was hard to download the plugin and install it and find where to install and decide what the path is. But there's a TPM, TPM is T-Max plugin manager, kind of like brew just for T-Max. You just provide one line in the corner, you run it, that's it. You have the plugin. Amazing. So just like anything else, just provide something within the repository. The user is looking for to me, even though everything you said about home brew is completely right. It's just easy, right? You run brew install in your readies. You have readies running in your system. Yeah, that's it. I just gotta say something about you in a terminal. It's like the human being, like humanity are trying to get into the moon and to Mars, but Omer is trying to get into the terminal. So one day, we'll just find Omer in the terminal playing with the VIM. That's like how I vision you in like 50 years. You're just gonna be a terminal entity that plays with the VIM. Okay, I'll tell you something. Don't go to read it and go to and find rising. You know what rising is? No. It's kind of a term that was coined to describe people who are too much busy with tweaking their file system and their operating system and having the terminal show brighter and nicer and VIM is tweaked with all the plugins and everything. Far more than you should, right, for productivity. It is for the fun of it. So that's rising, look for it. It's a rabbit hole, you'll never come out of. Wow, you're probably living in rising then. Yes, I guess so. Why, okay, okay, okay. Moving on, moving on. Now, I think, again, I think the GPT provided steps according to some logic that it has, but it's not necessarily good because after the design and system architecture, I got the backend development and then font and development, then security testing, deployment, blah, blah. So I'm not gonna go through everything, but let's say after we got the system design and we got the maybe initial setup because we got system design, we know what's gonna happen. This is going to hit that. We already chose the architecture. Okay, we started writing down some code, something. What's the next step for you, Emily, usually? Like, would you invest more in local development and maybe more distal within your application manually to friends? Or would you start moving it to CICD? Like, how would you, so you're in a crossroads? You've finished writing down something which is quite okay. Now you need to distribute it, but if you start writing a CICD process, that will take time. I'm not saying it's gonna take days, but it's gonna take hours or maybe half a day or a day to make it sufficient to be okay, all right? Depends on what you wanna achieve and what you wanna do. And if you want to keep developing, you can keep developing and then distribute it manually. Now, before you even go to any path, if you go to the CICD path, remember, you need to create some repository to store it. You need to create credentials, you need to take care of hiding your credentials in the CICD system. You need to take care of a lot of things. And if you just go on and keep developing and distributing your things manually, then it also costs you time, each time to build and then talk to a friend, say, hey, here's the new version, maybe track it with emails. So what's your preference when you come into this crossroad? Okay, I'll be very straight forward. Just release it, first of all, work and releasing. Now, this is something I always try to follow, about CI, specifically that you mentioned. I always try to follow and I always fail. CI, do it from the second commit. Don't wait for it, just be as small UI and let it run. It will save you so many hours down there. It's what I tell people to start using VIM. It's so hard, it'll take hours and days to learn, but yeah, you're going to work, you're going to write code for years. You know how many hours and focus and energy you're going to save on fucking fighting with your eyes. Sorry, you can curse your fighting with your ID. Just have something that helps you work that's fun to work with that's productive. Same thing with your CI. If you run your code and you just push to main or push to a branch and everything happens for you, it's easy to just keep working on something as opposed to just starting to release it and copying to a bucket or to releasing to a specific repository or whatever. So you chose the third option, incorporate the CI CD during your development process. Yes, but I have one comment about that. You said it can take hours. So I'm not saying now, build a new Travis account and start releasing to something that you built from scratch. I just told you, I'm using something I already know. For example, I built the tool and I'm writing it in Go because it's easier for me. So I know the frameworks around that. I have something that's called Go Releaseer. If you take Go Releaseer, not only it releases everything for you, including Homebrew, Choco, whatever you want, it also provides the GitHub action. All I needed to do is copy paste the GitHub action, throw it in my dot GitHub in my repository and that's it, CI is running it to five minutes. The other 20 something minutes I spent was tweaking Go Releaseer itself to undo release the packages that I wanted. Not the CI with GitHub actions and everyone nowadays providing GitHub actions took no time. So I'm okay, I like it actually that like incorporating CI CD. So you can only add another step, another job instead of creating the whole shibang from startups. So like taking it in an agile way, you know, bit by bit and not finish this and then realize, oh my God, and it's the ICD. Let's hire a DevOps button. Even if it takes two hours to build your CI CD because you're not an ops engineer and you're mostly around code, it'll take you what? Two hours, three hours to build the GitHub action the exactly the way you want it, fine. If you're going to work on this project for months, it'll going to save you days. So you spend the three hours, it's annoying, but it's worth it. Okay, sounds like a plan sounds like a good idea, okay. So again, continuing with the list also see I told you a security testing and deployment. So I, okay, so I think from now, okay. I think we're about to finish. I think this like, it really depends on the product, the team, the use case, you know, now it's too specific. So I think we covered the basics. I'd say we want to like, let's do a short summary of like the good points that we did. I can give one sentence on something you said, which I think is important. You talk about security. I'm not saying now do something very robust for security. I'm just an example that I have in mind. I'm building a tool to authenticate with AWS. Obviously for testing, I have, even though they were temporary, I had temporary keys lying around my code because I needed to test stuff and have it run. It's easiest thing in the world to just make a mistake and push that to main on GitHub. And I already have a CICD, so that would be realistic to homebrew with my keys, right? So what I'm saying is just using any type of tool easiest thing in the world is just go to what they call the famous Slickstool Gitlix. Just use that and it locally checked that nothing's funny is going on and then push it to GitHub. Once you have that, I think that covers like 80% of the issues that you can expect for hitting licks. So even before talking about testing, because I won't talk about testing, I say let's go start to end of what we just talked about in a minute. Start to end, okay? So it's gonna be like, a little, little, little, little like this in a minute, okay? So first I think we covered and then you need to back me up and fix me, all right? So first I think we talked about just start releasing it, just start writing if you know or not. But then I also stopped you and said, hang on, the technology stack is something that we should choose like in the end probably. So I'm gonna mix, I'm gonna do a mixed summary. Let's have a real good first step. The very first step, you have an idea in mind. Right, let's get it. I would just get you. Exactly, lay it out, pen and paper, whiteboard doesn't matter where. Just lay it out, share it with a friend, maybe a friend like Omelette will tell you, listen, I know an amazing tool that doesn't specifically that you're wasting your time, that can also happen. Unless you're really keen on writing code now and you wanna build that then, yeah. If it's writing the project to learn about the language, sure, go ahead. But if you wanna write the project because you're saying, listen, this is a need, the world needs this tool. We need it, the hero, the hero we need, yes. Yeah, the hero, I also wrote GitHub Actions Hero, by the way. So I wrote an action for like, which is named hero, which does a lot of things, so I just named it hero because it's the hero we all need. Okay, so sketch it, share it with a friend, get to references, get more ideas or whatever. After you sketch it, you should probably start writing down the function like a bit of the functionality of what you expect to happen. Again, if it's a small tool, you can just start writing the code or write stuff and shoot it, okay? If it's a bit more, when I say a bit more, usually I talk about microservices. So if you got like font and back and all stuff like that, it's probably best to sketch the process and the flow in your sketching, okay? Moving on, you chose your technology stack, you chose in which language you're gonna write. I'm not talking about technology stack in the cloud. I think that's a whole different conversation because that's like the deployment stack, like how it's gonna be served in the cloud if it's a web service, okay? But that will be left later on. Also don't deal with it in the beginning because it will drive you crazy. How do I do terraform? How do I do the infrastructure? You will go to sleep. And I don't want you to do one of the things. Yes, we want you to work. Okay, so you write down the code and then you share the MVP with a friend, right? Like Omele said, he shared a screenshot with his team leader and then had to look for a job, remember? Yeah, okay, so that's like, I think the summer is so far that we said, right? And now I think you mentioned a few points like that we talked about, like the wanna mention some more good points like besides sketching the idea, right? And we talked about sharing. Yeah, having something automated to help you release, release both in the sense of CI and providing it, like incorporate CI, CD during the development process. Yes, bring it all the way to a point that you can at least share it via one repository and not having to send a binary around, although that's a viable option if that's what you think is good. Preference, again, I'm working with Homebrew, I'm assuming I'm using a max, assuming my user is using max, I just go there. Regardless, just choose whatever works for you, but yes, incorporate that into CI. Make sure you're not leaking anything because that would be a shame. And another tip I can give for any development process not just for starting a new project is you said that I am writing down my keys in the code or whatever. So I think like I love the test-driven development. Well, when I start developing, I just love to write tests during my development process. Because as we all know, if you do it after a while, you're like, wait, what did I want to test? And then you're like, oh wait, I added this feature. Did it mess the other feature? So I love, like, instead of manually inserting other values to check other use cases, every time I want to add a new feature, I just write down from the beginning, a very simple test suite. And in Python, it can be with unit test, Python, whatever, you know, you got just site place and whatever. So you got tons of unit testing frameworks that you can work on. I'm not talking about testing the graphical user interface or something more complicated. Just testing the functionality of your code to make sure when your features are not getting broke or are still working as you expect. So besides making sure that the code is secured and not linked, I would say also write down tests. And on that every time your camera is burning like hell. You don't see my faces now. Ha ha ha ha ha. Amazing. So I think it's also a good time to move on to the corner because we think the summary is done. Yeah, I'm sorry, I could show my face I would. Okay. So are you ready for the corner? I am. I just see an O now on the screen, O for O no and for O no. Maybe so. Maybe I just changed. Call the corner of the week, are you ready? Yes. Corner of the week. Well, O no. What have you done this week? Can you share that? How about this week we started with yours and I will try to make my face work while you're stalking? O wa. Good one. Tackel. Oh, okay. Sure. So this week I am working a lot on migrating from big buckets to GitHub. And let me tell you one thing. Wait, why is it if you have an and it can happen? You know, even though you don't really like it, it can happen. If you have a very large file committed to your big bucket repository, let's say a file which is more than 100 megabytes. Okay, beat bucket allows it just so you know, you can commit files more than 100 megabytes. Okay. That's amazing. Then if you migrate your repository. Wait, what size more than 100 megabytes? Why would you need the larger? What is it? No, that's okay, no questions. We just say, okay. Maybe it's something, maybe it's not a binary. It's something I don't know if some people have those things in their repositories. But just in case you have something that big that you want to the the tribunal repository and you want to migrate your repository to GitHub. What you meet along the way is a restriction by GitHub because GitHub are more like OML. And they do not like files more than 100 megabytes committed to a Git repository. They do not allow it. They even send you a warning when you commit a file more than 50 megabytes, you get a warning. It's time to come to your home. You know, it's funny because I found out about all those roles and warnings like on a real life scenario. You know, it's like I really experienced like everything. So files more than 50 megabytes, if you commit it, GitHub makes it in the warning. Wouldn't it be funny if someone knocks at your door and saying hi, I'm from GitHub. You uploaded a larger file. Yeah, show me your computer and now I'm waiting. Yeah, and they will throw your computer out the window because you're doing nonsense. And leave a sticker, GitHub sticker, and walk away. Oh, walk of shame. You know, like do a walk of shame, you committed a file more than 50 megabytes. So a file more than 50 megabytes in GitHub gets a warning, a file more than 100 megabytes gets. A person detected, rejected, you cannot. So if you're doing a migration from a bit back to GitHub, you'll have to start working. Unless you're saying, listen, this file is no longer needed also in the history or whatever, you'll have to move to GitHub FS. Now, if you haven't worked with GitHub FS before, it's not that nice because it means all your developers also needs to work with GitHub FS. So then it complicates the whole development process because every time someone clones the repository, they also need to do GitHub FS in it, then download the files, blah, blah. Just to be on the safe side that we know what is GitHub FS, it just instead of having files commit to the repository, you have pointers. And if in any pointing of time, you want to download those pointers that instead of having the pointers, you want to have the actual file, you need to run a command that will actually get this file from the GitHub FS server, okay? The GitHub FS server usually resides where the old Git provider is. So GitHub has their own GitHub FS server, a bit bucket has their own GitHub FS server, and you can have your own whole self hosted maybe AWS S3, GitHub FS server, whatever, okay? So I had like this huge problem where I first said, maybe we will rewrite the history of the repository and then move everything to GitHub FS in Bitbucket and only then move it to GitHub. So there are so many options. Mary, that doesn't sound like you had fun. No, like so many options, like in how to do, how to do it. Eventually, you know what happened, which is like I think the most basic thing. So I'm still trying to figure out, blah, blah, blah, blah. I talked with the people and we decided that this file can be deleted. So instead of migrating to GitHub FS, instead of rewriting the Git history, which is something that I'm trying to avoid in any... Just S3. Like S3, what I'm trying to do when I wake up in the morning, I'm trying to avoid the rebasing the history. Okay, that's what I'm trying to do. Okay. So like before the migration, we decided, we don't think this file anymore. So we are going to delete it from Bitbucket, okay? We are going to rewrite the history, like this file never existed because it's not really in news today. And if somebody by any chance will need it, we'll upload it manually to S2S3 and then we'll leave it at S2L. But I think you got the idea like sometimes it's even better to a device with these stakeholders, which are the team leaders, VPL and DC or whatever. And not solve it technologically because moving to GitHub FS would complicate all the processes in the company. It's a pain, yes. Yeah. So that's my tip before if you have or need to migrate between Git systems, large files, everything. So check it out before you even try to migrate because the migration process is also something huge that we can have an episode about, you know, it's crazy. So what did you do this week? Okay, I have too many tools. I'll pick this one. Okay. Well, actually this week, every time it's tool, you learn so many tools. I don't know how you keep on learning new tools every week. It's crazy. I just can't get out of it. It's a look. So I'm only in the world of tools. And I, you know, like 1000 between five. I can't cook anymore. I can't eat. I only deal with tool tool tool tool. Yes, yes, yes, which tool which will be honest. It's something I talked about in the past here, but. So I talked about terminal multiplexer and the way I like to work with my terminal and that kind of helps me stay productive. And my go to was always Timox. There are all their alternatives like screen in the past and some others if you've heard of them. However, there's a new one that I mentioned before called Zellage and Zellage became quite famous. It's a rust project already has like 13,000 stars, something lots of really enthusiastic users. It has some really cool features about it. One of which is that if you don't know terminal multiplexers, I mean, starting with Timox is a real pain. You need to learn the prefixes and the different commands and it's hard to get started with. With Zellage, the idea is welcoming newcomers. So it's a very self explanatory. You just fire it up and you have different commands with logical names explaining what you should do, giving you tips down in the bottom. It's very configurable. It works fast, it's really nice. It has tons of features that Timox doesn't have like floating pains and the ability to cut and copy and alter your terminal is really nice. Check it out. I made a video about it on YouTube. I just uploaded a video kind of reviewing that and I was a few months back. And then the own and I watched an interview with the owner around and at one point he just shot an email or sent me a Twitter message. Don't remember, he told me I really liked the video. Let's chat. So we hopped on a call and he told me I really liked it and we talked about reviewing other stuff and this and that and he kind of shared what he's doing. During the conversation he told me do you wanna switch to Hebrew and I said what? And I said, yeah, I've lived in Israel, I speak Hebrew. He used to live in Israel. Now he lives in Austria. So we had a nice conversation and my news is now getting to the actual news. Zellage had a few kind of pushbacks. It's really nice, it's really easy to use but it doesn't have a few major features Timox have like resurrect, for example, the research is a plug-in for Timox. If your computer shuts down or you restart, it can fire back up with your entire set of windows and paint and everything, the layout is saved for you. And changing different sessions. For example, in Timox you have, you can change between different sessions. You can have a private one, work one, development one, whatever, Zellage didn't have that. It only had different windows. So all of that is coming now to Zellage and it's just gotten new release two days ago or something like that. So point is go check it out, it's really cool tool and hopefully I'll be able to make another video about the new version. That's it. Cool, sounds amazing, I don't think I had a good week. Yeah, that was just one hour of my week, but yes. Okay, so I think we're done. Yep. Okay, so thanks everyone. Thank you. Thank you for joining. Thank you for joining, Elvis is not here. He will join us next time. Think about all those URLs or maybe listeners, not viewers who are listening to our podcast and they have no idea when you say well, Elvis when we talk about it, they have no idea what we're talking about. So maybe I need to take a picture of Elvis and then I think you need to buy the main name, call it Elvismail Elvis.com and put a picture of Elvis. So the next time we can tell them go to Elvis.com and find my request. And that will be the only purpose of this website. Yes, about plenty according to the entire set of tools we just mentioned. Oh, I'm gonna go. I will, yeah. Okay, so almost camera light that again. Okay, so thanks everyone for joining and listening. Thank you. See you next week. Bye bye.