TOA Part 1: Developer Experience

everyone happy wednesday i have to shut the music off i spent like my entire afternoon trying to get the multi-track audio working at least in the recording side um and i could not get it to work i'm convinced that this stuff just doesn't work on mac and maybe i should stream for my pc or something but um anyways sorry i had to shut the music off on you but i will keep working on it and hopefully we can get uh some cooler streams going here in the future welcome back everyone i'm excited to keep working on this new project that we started last week uh too much grain on the screen um interesting is that nope that's making it worse interesting i wonder why i don't know what's up with that um maybe it's somewhere in my webcam settings but let's uh let's switch to the coding screen and hopefully if it's still there at least it will be uh less noticeable for y'all um in the lower left corner oh that's probably from my macbook screen let's do that nope that's about it what is what is going on here well that's that's off we don't want that is that a little better that's a little better i can still see that the webcam looks grainy but the light went away all right always a learning is it refracting from something well if it is it's refracting from chad haas's androids book that's literally the only light colored thing on my desk um and that made for a really great joke has anyone in chat read this yet how is it um i have not even opened it you see no bookmark or anything because i'm in the middle of rereading harry potter again but i'll eventually get to this um i look better than most people on a webcam i appreciate that um as the regulars all know but it looks like we might have some newcomers here uh i'm always working to improve the stream a little bit and like the setup and everything else it's come a long way from like our very first uh streams but um yeah the problem is i just never spend time to actually invest in like making the overlay look pretty and stuff um i want to for example some of you may notice on the bottom left of the screen uh we have this really scuffed um text list of the things i want to work on today um was talking to some friends about how i could make this like really fancy and use like a browser source and basically build like some html and css code that would show like a list of everything i want to work on and make it fancy um did not have time to do that all today but i realized i could set up like a little text source so i've just got some text on the screen that shows everything i want to get through today and then as we do it i can check it off and i figured this would be helpful for like as people show up they can see what we're working on what they might have missed but what's still coming um function over form initially yeah that's exactly what i was going for um and make sure that like we actually like the idea you know i'm curious all of you watching this let me know at the end if you think this is helpful um and then i'll know if i should invest more time but it's actually really nice and it's pretty responsive so if i save the file i can already see the screen has updated with like marking something is done obviously we haven't done that yet um but we will get to it and uh yep ship it thanks for prince for helping me out with the idea um but these all have there's a little bit of uh rhyme and reason to why i have all of these tests in this order uh and that's specifically around danger um some of you have seen before i've done a stream where i showed how to add danger if you haven't the short answer for now is it's um a tool that runs on like your continuous integration and it does some pull request checks for you uh but beyond like the typical ci stuff like it doesn't do like unit tests it's not meant for like unit tests and like does your app build it's more of like a i've seen people describe it as like a linter for github so let's say that i want to enforce that a poll request has a description danger can check like the length of your pull request description it can verify that you've added labels to your pull request it could look at like the number of lines changed and then send a warning if you're making a really large pull request and i've got some cool things i want to do with danger that relate to the later steps in this process so um we'll get to that but before we get to danger uh it needs to run on something and that's where github actions come in so um we'll probably start well i think we'll start with github actions first um and yeah if you want to follow along beyond what's on the screen um we did last week we set up a bunch of tickets in the app for what's the word things that we want to work on for a good chunk of the app and this project board here developer experience this is what we're going to start with and let's bring this down because that red bar looks weird we'll start with uh github actions here so also just quick plug exclamation point youtube if you need the youtube link if you want to watch last week's stream um all of them get uploaded to youtube after the fact so do check that out if you missed last week's but let me know if you have any questions about the app that we're working on we really haven't gotten very far actually if you're just tuning in for the first time we're starting this new app i want to make this wholesome to-do list application and you're witnessing basically the first effectively the first stream uh last stream we made the repository and we made a bunch of github issues and talked about what we were going to build but we've and aside from implementing the like android studio template we've effectively written no code so if you're just tuning in uh this is a great time to have joined us and i hope you learned a lot so i'm gonna dive in uh always as always stop me a few questions interact um yeah let's let's dive into github actions so i'm going to pull up my notes on this other screen uh where i can show you all how it works but if you've never used github actions before it's a continuous integration tool managed and run by github and it works like a lot of other ci tools if you've used them before where you need to make like a yaml file that's a yml file uh of what steps you need to be run and where that lives is inside our route um we have not used room but that will be coming up in a future stream i don't know how far away but we will do that in this project but the github actions they go inside a new directory dot github and then i believe the next directory is workflows let me double check this yes and then inside here we can run um all of our uh words all of our github actions that we want to set up so for example i'm going to start and i'm just going to call this one android build and what i want this file to be oh i should also be on a new branch before i forget sorry brain just totally forgot i want to make sure that i have branches set up for each of these so let me go back to this ticket so we can talk about it something i want to adhere to for this project is um interesting kalusi can you send me uh something on twitter if you're on twitter and i can try to help you out with that um let's see what the issue is but one thing i want to be strict about on this project is making sure like i have clear branch names and i'm always tying my code to the issue that i'm working on so the way i'm going to do that is keeping this issue number number six when i make new branches um i'm gonna do toa dash picket number and then do a little slash and then some description we'll call this github actions that's going to be the convention i go with it's very similar to what i use at work so now it's just kind of a habit but this will help me with uh remembering something cool i can show you when we commit code so let's add this android bill um what do we need to do here looking don't mind me i'm looking at another project because github actions once you've done one became one of those things that you kind of copy and paste across projects so i always forget um how it all works but rather than copy and paste for you all i'm going to run through this and talk about all the steps in case you've never seen a github actions file before um so the first thing you need to do is give your action a name i'm going to call this android build um we give it a trigger like what this should run on um which could be like on commit on push on pull request uh in this case i want this build to run every time i push code so we're gonna say on push and then we give it a list of jobs uh like so i'm gonna call this one build and then we've got to use a few things so we got to tell it what kind of runner to run on uh we're gonna have this run on ubuntu latest this autocomplete is wild this is this must be new in a recent version of android studio i've never had auto complete for github actions before this is very cool um and then we need to give it a list of steps to run and this is where it gets fun so one is let's see so we need to use this which is we want to use this actions checkout or action slash checkout step which will um check out the code that's our first thing um i have this one in here that i'm not positive we need still um but i'm going to add this anyways so i've got this setup java one in my other project and the reason for that is because uh we want to set the java version to 1.11. um oh actions audibly came in bumblebee that's interesting because i'm not on bumblebee this should be the latest stable version that i'm running here i can double check but um i don't know if github actions is using java 11 by default but the reason this was in here is because it wasn't in the past and that's what some of the compose stuff needs so we got to update our job version um and then we want to do two things on our side uh first we'll say we want to build the project so to run this we do dot slash gradle w assemble and the other step we want uh will be run test and to run this let's do real living test okay so this should be um everything we need for today oh while i'm here i also while my brain is jumping around um i learned about this setting somewhere uh where you could indent your folders where was it at uh i forgot there's a way to change the indentation that's used in the project window and i thought that would be really helpful on stream to um it's in here somewhere i'll have to look it up uh but there was a way to like shrink the indentation used on the left side here it's an appearance um menu and toolbars maybe uh it would probably be faster if i just looked up the tweet oh use smaller indents and trees this option right here and then we apply and you might not have seen it but this just shrunk over here on the left um and so now when especially when we get further on in streams and we're pretty nested um i won't have to keep like sliding this bar for you all to see like where i'm at so that's pretty nice okay cool this is our first github action um i'm going to command k to commit now the reason i like the branch name to have the ticket number like this is because if you like you can see this here if you reference the issue by using this number sign um github will create a link between this commit and that issue so i'll show you what i mean i'm going to say adding android build action for number six commit and push push and also we should i'm gonna move this to in progress real quick but if i now open up this issue we can see some stuff that i did to it but right here adam added a commit that referenced this issue and then it shows me like the commit that i made and i can click on this and here's our commit so one of the reasons i really love working with github is that if you're conscious about these little uh ways that everything connects it becomes super nice to navigate between all these pieces of information that even though they're separate the commits the issue the pull request are all distinct things you can do some work to make sure they are connected with each other which is pretty cool um before we merge this looking at my other project um and i've got um another action i want to add to this so also keeping in mind like we don't have any unit tests in the app we also don't have any ui tests in the application but eventually we'll get there and so i want to also write a workflow that runs the ui tests or would when we write them and so i'm going to add that workflow real quick and i like making that a separate one because the ui tests take a while this way it can run in parallel to my other actions so let's call this one android uitest.yaml uh yes okay and now that i've explained to you um the general setup of the github action i am going to copy and paste this one but i'll talk through it real quick so all of this stuff is the same we give it a name this time i want these to run on pull request again because this is kind of like a little heavy i don't want it to run um every time this one is set to run mac mac os latest i'm not sure why i made that different um maybe there's a reason between what we're going to add next which is we need to run tests so let's add that reverse some indentation here um and that this and i'm gonna make this cap lab um this uses a public uh runner from reactive circus which is like an emulator runner and then you give the script which is connected check and so this will run our ui test for us um i'm surprised i didn't give this one a name i just noticed that i'm gonna do that here uh but okay so we've got that's our ui test so let's push this one up we will make another one for our next step danger but we'll come to that after um adding android ui that's action for number six so we'll push those up um and we're flying through it so that's good hub actions this is a great time to ask me questions because i'm going to make a pull request and once uh this is all done i'll merge it and we will um move on but uh let's do this so we will say um adding um android build ui test actions uh i don't know what i'll say here this is one of those tickets that i think is kind of self-explanatory but i could leave a note here yeah i'm just going to leave it blank this time uh i do want to give these labels um do i have like a tech that label would be a dell and i'm going to add one back that not really debt yet but we'll create it we'll also give this to the developer experience project um let's create a pull request so i'll talk a little bit um while we wait for these actions to complete um [Music] actually once they do oh we got a cube solved that's a great way to kill time while this pull request happens um so let's do that real quick uh yeah we're just waiting for the actions to run uh let's do this i'm gonna lower the camera that helped last time um for you all to see this problem is i can't really see because i have all the other lights off in this room but hopefully the ring light will help me uh be able to see here so oh god now i am i am very white uh someone has something to say about that let's mix this up real quick i'm just following the scramble that's on the screen oh did we want um [Music] uh is there any limit um [Music] that is a good question uh i know that if you have private repos there is a limit i don't know if one exists on public rebounds actually i've only ever gotten a warning on a private repo i have that uses this um but hold on i want to see if i can um do something really quick um i don't know how to do it someone suggested last time that um someone suggested last time that i had a prediction for like over under 30 seconds um but i couldn't find it but i'll look into that sometimes we'll do this but uh taking a quick look at this um this is gonna be a tough one i think but okay are we ready let's make sure i'm focused over here you can all see this right and go let's go oh my god i haven't been under 25 seconds in a while that was great that that got me pumped that was that was very good amazing all right let's bring this back up all the streaming is just practice for keeping yeah let's do that a gradle well the bar is low um while we're on this page um i realized that when i made these kanban boards i didn't include the uh automation to like add pull requests but i kind of regret that so i'm going to manage this automation um say when i add a pull request it should get moved to in progress um and then on my done um when pull requests emerge they should get moved to done as well uh this won't apply to the pull request that i've already opened so let's go do that real quick um we'll put this in in progress and i'll update the other boards later i'm going to keep solves long as you build um also not many of you may have noticed but i did go through today and i actually changed some of the point rewards or the um the channel points required for a few things because i realized other than hydrate no one was really engaging in the channel rewards so uh it's still pretty high but i dropped down the requirements for the captain america um and the code review i think all of them except for hydrate is still 200 uh points but and some other stuff now if you were closer to captain america you are even closer now or you can do it um okay that's building but i'm gonna go ahead and even i'm just gonna mark this as done anyways uh let's see if this is almost done um it's the classic it's the ui test something else we can do while we wait for that is um on branches we can add a branch protection rule these are fun bye prince have a good night and for like the development branch one thing i can do here is require static checks to pass um and can i not i want to require oh android test i think that's what it is oh maybe it's because the other one hasn't actually finished running yet but i can mark like android test as something that is required to pass before we can merge so that's really nice i like that as like a safety net so now if we go back here all checks have passed nice i'm actually a little should i be nervous that i don't see my android build why didn't android build run for the latest commit oh it failed question mark every step must define a uses a run key oh maybe when i added this name i broke it oh there needs to be a hyphen here that's one thing that's different um oh no i don't want to become famous oh god um hey matt while you're here can i do this from here now i was gonna make you a mod i'll do that later if you're ever around and are willing to help out um okay i think that was just a typo in the action uh so let's push that up because i i'm eager for this to finish because i want to show you all something cool when you merge the pull request another cool thing in automation and i think that uh i'm going to be overzealous and i'll just merge this pull request with my administrator uh privileges to show you but um as i mentioned anytime you reference an issue number and like a commit or in a pull request description or anywhere um it will create a link but there's other ways to do automation which is that if you make a commit that uses a keyword like fixes or closes followed by a number github will perform some automation to close that relevant issue so for example sorry just playing around with this um if we do splash and merge here um i can delete these but what i can do is um at the front this is going to be the commit message i could say fixes number six and i'll leave the additional information here but if we now confirm squash and merge this is pretty cool so now the pull request is merged look automation move this to done but if we go click on number six now it's closed and then we can also see that a developer experience automation move this to done so if i go to that board now i can see our actions ticket is done and the pull request is in the column so we've got some nice automation going there um yeah that's me i just want to show you the like fixes number um there's a handful of keywords that work here fixes closes i know there are others but like those are the ones that i like um but now we can talk about danger for pr automation so let's do that um i think i have a link here so let me drop this chat if you all haven't seen it before uh there is i can't say when um actually i can't say this at all i was going to say i have some content coming out in the future around danger but i don't know what it will be um but this is like i said the way to enforce some cool stuff on uh your pull requests so i have dark mode yeah um but basically let's see um we can leave like comments like messages warnings you can add a fail which is like actually will fail the pull request um we can add some markdown um yeah that's the short answer so let's um let's add this and we'll talk through a little bit about how it works on github actions so the first thing is as i mentioned we're using this is a ruby gem so one thing we'll need to do is at our project root we need to add a gem file and we can just type gem danger that should be all we need here but then in addition we need something for danger to run which will be a danger file and this is where we could put all of the cool code to show off about what was added so pulling up another project for reference here sorry um we can put like this let me show you all this we could put a message in here that will like at the author and say thank you for the pull request let me run this make sure we can get our danger set up working um before we do anything i'm also still on my old branch because i got distracted so let's go back to toa here um projects developer experience uh number five let's go to a new branch here voa 5 danger okay um what else do i need i think we could start with this um but we also need something to ah recap sure uh let me fill you in larry so we added we just added some github actions these are like ci integrations that will um that will fail apparently uh but they'll run and make sure our app compiles we'll make sure our units test pass um and all of that fun stuff uh so that was step number one today uh the next thing we're working on is this tool called danger which i just dropped in chat a few minutes ago let me know if you don't see it um let me spend a little more time explaining what danger is because i didn't do that so let's zoom in let's talk about these stocks so danger runs during your ci process and gives teams the chance to automate common code review chores um now this isn't the same as automating like code checks like we're not testing linting we're not testing you know compilation or unit tests um we're doing more um meta checks on the pull request so over here is some really good examples right so like uh we could say please include a change log entry you can find it at changelog.md i actually want to add something like this to our project because i've got a file in the app for stream history so every time we stream i'm going to put an entry there and record some like notes for people to find and so i'm actually going to use danger to hold me accountable and make sure that i modify that stream history file we can also have it check that like you've added a summary to your pull request description um this looks like it does do some ruby lit check or there's another message like um i'm not sure what this it's like maybe you're adding someone who's not part of your organization these are some of the checks um and this is built by the way using the ruby language so let's look at a couple other examples so yeah we talked about um you know making sure that we've modified the change log it looks like you have a way to like highlight build artifacts so this actually will output a message uh that links to like your test reports uh this is really cool i should do this in the capsule app um what else like making sure there's no merge commits if that's something you care about um yeah these sorts of checks so we haven't gotten very far uh all i've added is um this one task that will send a message and thank the author i'm going to make a pull request to ensure that this basic setup works that i can get danger to run on a github action and once i know that it runs we're going to come back to this file and we're going to add those checks that are related to this project is it related to code coverage it could be you could have it leave some messages based on code coverage but it doesn't have to be um so in order to get this to work by the way we're going to add another github action uh for danger checks whoops dot yeah that didn't add the extension and um let's go in here and so i'm again now that i've kind of explained github actions i'm gonna copy and paste some stuff so let's copy up to here we can do this so this will be danger checks it'll run on pull requests check out so we'll check out we'll set up our jdk we'll set up ruby right now technically we don't need the jdk but we might do something fancy later so let's add a couple things we need to add here i'm going to paste this and then remove a couple lines that are irrelevant and then we'll talk about it okay so what we've added here is okay i think the indentation is wrong on this this one we've got okay so this step we call danger checks to run this little pipe character is how you um set up a github action to run multiple commands so the first thing we're going to need to do is install bundler then we do a bundle install this is what will actually install danger for us and then we do bundle exec danger and that will run everything in our danger file the other thing is we need to give it an api token uh and then we can reference like our github secrets if anyone wants to know more about where this is let me know and i can find the settings deck but this is basically a way that i can do this on stream without showing all of you my api key so let's push this up uh adding danger for number five and i'm going to make a pull request and i just want to make sure that the danger check actually runs and then we're going to come back and make this file our danger file more helpful pull requests compare um and danger things allows us to automate full request we're going to put this in the developer experience project as well and create pull request while it runs really quick now that i've figured out some issue stuff i want to go back to our branch protection rule and i want to say whoops i'll say build and it won't show up yet but i want to make build and i want to make danger checks also things that should be required to pass before we can merge a pull request let's see if they're actually running all right that failed what am i doing wrong here i have an error in your yaml syntax on line 27. i don't have anything on line 27. oh you know what maybe this needs to be like dude this is the right syntax cause that's what the other ones do maybe that's what i did wrong maybe that's why build was failing too actually it's very fascinating that um what happened that this doesn't recognize its gamble anymore um right guys i want to try this this might i think that's my hunch of what was actually broken this is what i get for not just copy and pasting it exactly as it worked okay this looks like it's set up to run correctly um and let's go back to actions and danger checks all right danger checks is still broken here um so it's probably referring to this env but i don't know what's wrong with that oh probably because that needs to be i bet you that was indentation it probably needs to be aligned with this run because the environment variable is relevant to this check that's probably what we did wrong yeah uh does it though oh it does i mean i guess but it shows on that blank line um so i think the real issue is that this next line is the error so let's push that let's check the real reason we squash and commit or squash and merge is so that no one sees the fact that um i've already used oh well those are for the other ones i've already used three commits trying to get danger to work and then i'll have to add more as i actually add danger checks this also is a little conflicting with the base branch i'll figure that out once i can verify that these are working is it not going to run again the build step is running so why is it david chester what am i doing wrong that's the same problem as i mentioned earlier that was wrong on this one edit the animal on their website do you get like additional code completion or something i can look at it really quick i don't want to merge any changes but oh this is cool you can see all of the actions over here and stuff and view some documentation this is very cool thank you for sharing this i didn't know that you could do this um maybe this is the way that i should have maybe it's on the other stuff but maybe this is the way i should have introduced github actions um rather than just copy and pasting from old projects why isn't this running though um i'm a little confused now that um this hasn't run in a couple of i think so i'm just trying to figure out why there are new chats on phone bus job stages i do wonder if um the danger checks action isn't running and i'm just not sure why like why this step isn't running what did i do wrong it tried to run earlier because it errored on this file uh let me look at my gen pile on the other one maybe that's something i should i just noticed some other stuff that's at the top of my gem file in this other project and i don't know if that's relevant i don't know if i need um any of this stuff but that might just be needed by ruby why is it not triggering this i i'm tempted to change this to push just to see if i can figure out why it's not triggering oh now it wants to run okay we'll see if this works then we'll resolve our conflicts then we'll try to get some actual danger stuff going on and fail could not find gem danger why not probably because it's a capital d maybe it's case sensitive gotta love case sensitive stuff i promise soon you'll get to the good stuff once i just have this working because i have i have good ideas i promise um boat's running i'll pull up the danger file on my other project so i can actually um see what cool checks that we do the nice thing is by being its own workflow that once danger is set up it should run pretty quickly um that's my hope anyways okay hold on this ran apparently do you mean it's not a github actions pull request it's probably because i need to change this back to on maybe i need to close and reopen the pull request if that's my issue um maybe that's why danger's giving me trouble maybe if i close and reopen the pull request they will trigger correctly um if it doesn't run again on this commit that's what i'm going to do yeah i think that's it let's let's close this pull request um and let's make a new one from the same branch that's fine um um ignoring there's some explaining on why i even did this i am very poor request like is there a typo is this not how it works no that's the right name uh but it's just very weird that it doesn't want to trigger the danger check why am i looking here no i wanted actions all right this is very bizarre um i have no idea let me resolve my conflicts while i'm thinking about it and then we'll just we'll see if i can figure out what's going on oh now it wants to run maybe there was something weird about the merge conflicts that was preventing the danger checks from running we'll also go into our settings and i also want to make that a required step for merging into development all right now i have a little more confidence nice it worked we got our thank you method message to the author i don't know why i was fighting random typos and stuff i'm sorry for making all set through that but now we can do some more cool stuff on danger so i'm gonna talk through uh some checks that i like to have inside of my poll request but let me know if you can think of some things in chat um but i want to go through a few that i think are important so like we could say if github.pr body that length is equal to zero uh we can actually fail and say please provide a summary in the pull request description um another check i like to do somewhere we have this um ooh i'm also gonna say if get that lines of code it's greater than 500. i like to put a warning here uh please consider breaking up this pull request um i also want to do um i like labels so i'm going to say if github.pr labels.m um also do a warning that labels this pr um what other checks can we write uh let me show you a fun one so uh with danger um something cool to keep in mind for your teams is not all of these ci checks have to be like i mean they should mostly be but they don't always have to be like serious and work related so i saw something cool that another team in my company was doing um and i wanted to do this so let me find uh which pull request that i put it in today um please hold yeah this is cool so one team has this idea they added that if you make a pull request where the number of deletions is greater than the number of additions it just leaves a message like woohoo code cleanup and i thought this was really fun like we all love when we can remove more code than we added so this is just a fun little message to say like hey good job thanks for cleaning up code uh so i think that's really cool to add um but yes there was another thing that i said i wanted to add in here for myself which was um specifically so it's up here if uh not get that modified files that include um what did i call the file stream history dot md um we're gonna say fail and then please update stream history with relevant information so every time i make a full request i'm obviously doing something that is relevant to the stream into this project so this is a way of holding myself accountable to make sure that every time i make a pull request i'm updating that document otherwise i might forget to do it after stream or you know information gets lost so we're going to add that check as well so i think that's what i'm going to add for today i'm going to add some other stuff to danger um possibly with um with some of the later work today but uh that's what we've got for now any questions on that any thoughts on that um when this runs maybe you'll be able to see even more how this can be helpful um to you uh because the whole point of danger is to much like continuous integration in general is to automate the small things so imagine if your team sets a standard like we want to use labels on pull requests because that's important to us for finding information later cool sounds great but that means every time you do a pull request it's like ah i have to go look and see if my co-worker added a label with something like danger you don't need to do that why is this wrong additions is wrong oh maybe it's insertions let me pull up the api reference over here oh it's insertions not additions sorry well that means my uh pull request that capsule's gonna break when this actually runs all right i think that with this we will have got it working i'm hoping for the best what are your thoughts chat do you think something like danger is interesting there is in a beta version but they are working on a danger kotlin that will do all the same things but you'll be able to write it in kotlin code so for an example down here like you would create like a danger uh that kts file and then you can actually reference stuff like um you know change log changed and then you can check like all source files that contains changelog.md so it's all the same checks but now it's kotlin code and we might be more familiar with because maybe we're not super familiar with ruby okay so this technically worked it failed for reasons that um yeah i feel like you shouldn't have needed as much time as i did but um yeah there's a lot of ways that can help out so this past but the reason it's failing is because of the intentional stuff the things that i'm missing also i'm not adding i don't have labels so let's add a label um this will also be techdet and let's update our stream history file while we're here so we are in stream two uh developer experience so in the stream uh we discuss a number of ways to help have experience and android like ci tooling and static analysis which we haven't yet but we will get to you what's this um date september 8th 21. i don't know if i need that here youtube vbd uh there's our blog the prs we can add these um so we added let's add this one um this is danger and i think um i could have actions that was two poll requests ago so that would have been 27. let's triple check okay click on this but i want to make sure 27 is the github actions pr it is cool um you know what i will i don't like how far that is okay there's just two in there okay so now we can actually move on from danger we can check another thing off our list let's do that um maybe we give it 30 seconds to just verify that uh danger does still pass but we should be good so i just saw the line going did the microphone pick up my burp because i didn't expect the microphone do that but then when i did that i saw the line with oh no i'm so sorry chat um nice okay so we got rid of our warnings and error messages so we should be good let's squash and merge this pretend none of this happened this fixes number five and confirm squash and rage beautiful so let's go back to our project of dev experience and talk about what we're going to do next um ah this one we're gonna remove from project we don't care about uh that pull request anymore so all right if there aren't any other questions on danger or any other ideas uh let's move on to adding kt lit to the project um i'm going to go in here before i forget another thing i'm going to do which will save me time let's go to development do not merge everything and then bla2 all right so if you are unfamiliar with kt lens uh this is a the tool is originally from pinterest uh which is a way of just avoiding bike shedding and automatically linting your column code and making sure that it matches um the standard kotlin formatting or any formatting rules that you supply really but then there's this project which is a gradle plugin that is like a wrapper around kt lint to make it really easy to use with gradle so we're going to add that and i'm actually going to pull up another project on the side and show you all how i'd like to add this to my project because i've got some interesting takes here i think uh the first one being okay so we need to go to our main buildback gradle file and this is where we add our plugins right so one thing i like to do i'm going to clean up these versions uh in the future like something the one i do with these because i like to put all of my versions in one place so for example something i might do here is i'm going to put inside this extension i'm going to put the kt lint plug-in version and then i'm going to specify what the version is and then i like to put a comment right above it that links to the releases so i can go here to see what's new and what the current version is for example since this is coming from another project this is probably not accurate anymore and it's not if you look at this one the actual latest version as of four hours ago is a 10.2 so let's um change that to 10. or 10.2.0 and then we're going to need to add this line down here inside our class path where we add the other plugins we're going to add the k2 link gradle plugin now the next thing we're going to need is um so let me show you this in the docs here so typically what you would do is somewhere in your groovy file um where is it at um so check this out so they have this line here subprojects this is a way of saying you want this code to apply to every module and then you would put some information that like configures kt lin and i like that idea but i actually do this a little differently is that i want to put the kt link configuration inside of its own file so the way i prefer to do that is at the root level i'm going to make a new directory and i'm going to call this build scripts this is where i put like relevant files and i'm going to put one here uh called ktlit.gradle and i'm going to paste the configuration from another project let me talk you through this so we've got our k2 and gradle plugin we've got the version of kt lit we want to use so this is an override so that like even if the plugin isn't updated i can use the latest version of kt lin right uh this shows like what outputs i want for my kt lint um like a plane check style and html report this is helpful that like when it prints to the console if any errors they print out as red um let's check real quick what the latest kt lit version is it is 42.1 um so this is our setup for kt lit i'll pause on this for another second so i talked about it really fast um but you'll be able to find this in like the show notes as well but what we do need is we do need that subprojects reference that we talked about before uh so let me look at how i'm supposed to do this because i always forget um but here inside our main build.gradle we're going to reference subprojects which again will get applied to all of our modules and we can say apply from then we do build scripts that a t or slash kp with that gradle let's sync this and then if we look at our gradle tests in the moment um it'll have to happen after the sink but we will see some relevant uh kt land gradle commands um we got an air i could not find kt lit gradle interesting um let's see if we can figure out why is this not in maven central um maybe i need this plugins that gradle uh one as well so let's add that real quick to repositories yep i think we found it now all right 18 seconds all right see look at the moment our gradle sync is still faster than me solving a rubik's cube but not by a y all right but now we can see we actually have a formatting task where i can run k2 lint format and this will attempt to modify a bunch of files to make sure they match the standard formatting guidelines spoiler alert i've seen this a million times this fails out of the box with android studio and the reason being um why won't you show me where it failed because i know where you failed but you just want me to go to the outputs um so one of them is inside example unit test it says there's a wildcard import so let's talk about that this file you can see here it imports assert.star uh kt lint out of the box tells you that you should not have wild card imports and i agree i don't like those so i'm going to go into our imports real quick because there's a way to do this um i just want to make sure we always use single name import i want this to be thing and so what we can do then is i'll remove that and when i import this uh it should no longer be star oops but that's also not the one i wanted um but a circ equals and the other place this will happen is example instrumented test we'll have the same problem so let's get rid of that line and then re-import this and we've gotten rid of those wild card imports so we'll run a k2m format again and now we've got build successful fantastic all right so one more thing two more things to do before we complete the k2 lint pr um we need to go okay sorry i'm trying to look at notes we need to go into i think i want to do this in the android build workflow and um add another step here uh below running tests we're going to call this um lint checks we're going to say run k21 check okay so this is um yeah this should be all we need and before danger yells at me again um actually let's see uh i don't technically know this because i haven't created it but because i haven't made any other issues i can preemptively tell that our pull request for candylit will be the next number available which is 30. so let's go ahead and add this um a lot of stuff changed here uh we'll look at it in the github diff and we'll talk about it um adam catesy went for number two and let me know if any of y'all have questions about like kt lit i'll show you in the github diff uh why all those files changed and how it actually helped us with formatting but let's make the pull request first so it's event um allows us to ensure our code base is formatted properly uh this will be we'll still call this one technet and we're gonna add this to delve dev experience project and pull request so let's look at some of the change files so well one thing so this uh dot ida idea file this um this is a way to tell the id how we ide how we care about formatting so for example that single name import the preventing wildcard imports that's effectively what this change tells android studio so we don't need to worry about the details um same thing here ah so let's look at this example instrumented so one thing kt lint did beyond us removing this import is it rearranged our imports so that they're in alphabetical order this is another thing that's important it's easy to reason about um your imports when they're alphabetical like that it also expects every file to end with a new line so a lot of what you see here is just adding a new line at the end of the file none of our examples on the default template had this but if you had a file that had like extra white space or something like that um this is what it would fix let me i could show you i can demonstrate that really quick uh so if we look at like our main activity um so let me show you so i'm gonna throw in a bunch of spaces here let's mess up this indentation more spaces there so you can see a few examples of where i screwed up the formatting right so if we now go to gradle and we run k2m format you can see all of our code shot back to where it was supposed to be so this is really nice if you accidentally add white space like you don't have to think about that you just run this and it fixes it for you uh so that's really cool welcome back matt we just finished adding kt lit and giving a demo on how it works uh basically showing that i can like screw up code mess with indentations and all that other stuff and then i just run this and everything is back to normal what's the difference to just using reformat file of android studio good question so some of that um you can i think some of it i think for most parts it's the same i think there might be some things that are formatted differently uh but another benefit i think of kt lint is that like you can use the gradle plug-in and then like run this command separately so one thing we're going to look at at the end is i'm going to make a github that will every time before committing my code runs this command so i truly never have to think about it i don't even have to reformat an android studio i can just type my code and commit it and trust that like the git hook is going to run it for me so that'll be really cool to look at right yeah matt called up a good point um that it's not guaranteed that they're the same uh but they should be for the most part i actually think there's some ways you can do it in the commit pop-up um so i think if you're if that's what you like i think that that's fine um i'd have to think about this if there's a real reason to maybe hypothetically although i know that there is this idea a dot idea file um that should mean that everyone on your team has the same configurations but i also would be concerned that um right that's kind of what i'm saying like even if other people use android studio i'd be a little nervous that there'd be somehow that they have slightly different settings um so a tool like this would ensure that it was standard no matter what all right um everything passed except the uh test yeah also can i could i even make a ci validate formatting if i'm only using studio that's another way to think about it i don't know if that's true all right so we added kt bling now kt lit does our formatting but another thing is um other static analysis like code spells and this is where detect comes in so detect is another gradle well you could use it as a gradle plugin but it runs other static analysis checks for you it will look for now think of things that aren't formatting but things you can check statically like is my method too long am i consuming too many parameters do i have too many functions in a file am i referencing a magic number like am i just using one two three four somewhere in my code base and have no indication of what one two three four is that's the sort of stuff that detect will look at for us um so let's add that let's pull up my other project so i can copy some stuff over because that's what we're doing at this point so we've got our detect version um oh that needs to be in a new thick class so detect is going to go on to um number three also before i forget because i already forgot we can put a little check mark we have completed the kt length step so we're over halfway through the stream now um all right build that gradle file we're going to add detect version and we also need to add the plugin down here and i think the way i did this before i think do i have a detect file [Music] oh my god sorry i'm like staring at my other screen and i can't find what i was looking for got it okay and same thing we're going to go into build scripts and we're going to add a detect.gradle file in here and this will be our detect configuration so we apply the detect plugin we tell it where our config file is this doesn't exist yet but i'll show you how you can create it and um the type of reports that we want and we also need to then we also want this to be applied to all of our sub projects so let's do that so i'm going to do a gradle sync real quick and then i'll show you a cool command that will come up in our gradle tests i have to wait for the sync to complete for this to work so somewhere in here um it's not that's none other doesn't help nope where are you at i know that you're in here oh maybe because i have to look at tests i know the name of the the task i'm just trying to find it aha when do you add the detect plugin hit control controls i don't think do i need to type i do oh my god this is really cool i had no idea you could do this all right so there's a task that comes out of the box with the greater plugin if you can read this it's called detect generate config this will generate a default detect config file so we're going to run that and then that actually gets added right here inside this config attack detect so let's add this to git real quick but this configures everything about detect so let me just show you an example so one detect check in here is too many functions and you can see this will show you like what's the threshold for functions in a file functions in a class and interfaces in enums should you ignore deprecated in that account ignore private in that account detect is very very highly configurable um i'm going to leave everything as default as we go through the projects we might find something as very strict like i found in my experience 11 functions in a file that's small um unless you say you know ignore overridden but especially on android like if you override like four lifecycle methods like that's almost half of your threshold already so i tend to bump this up but or you could turn this off entirely if you don't care about this being recorded but this does so much for us and i think most stuff will work out of the box but um let's run uh detect and let's make sure that we don't have any issues out of the box but we could actually i can think of a spot that we might with some composed stuff yep this failed aha and this comes up every time in a compose app so this is failing because the tech thinks this hex code right here is a magic number now they're not wrong right like what the heck is this um but in this file it it actually does become kind of clear like this is a hex code used to create this color but anywhere else if i was just passing in a random hex code into a function you can see how that would be weird and not self-explanatory so one way i do it in this compose thing you know is i just suppress it and i can actually suppress it for the file by doing like file suppress and then i could say magic number and this is a way to tell detect um don't run the magic number check for this particular file but anywhere else that i have a magic number it should definitely warn me so let's add that and now detect is passing again awesome so let's we added that if it looks good let's add another bullet point here um detect this will be pa 31 and we'll add this adding detect for number three you push this up and uh we're almost done so once we finish this detect stuff once i verify that the pull request once i make the pull request and merge it we can look at the githubs the get hooks i like to use for my android projects which shouldn't take too long we'll do a little bit of copy and pasting but i'll show you a really cool trick that i learned from sebastian who does code with the italians on how you can share good hooks with your team uh that's very cool so let's compare pull requests and detect for number three detect that um developer experience we'll say the text allows us to perform static analysis checks that look for code smells in the codebase okay grateful yes so just give this a second basically for oh actually what i would have liked to add to this is um in our android build where we run lint checks let's also run detect here um i know it's not like lint but i think it makes sense uh we can even change this we can call this static analysis or something running detect actions and so this way we make sure that detect is passing as well well consider breaking up this pull request okay this makes sense the reason this pull request is so large is because our detect file alone adds 746 lines um so it's good to see that um this danger check is working uh but we don't have to stress about the size of uh that pr um at this moment anyways okay so just gathering myself to think about how i'm going to explain the good hook step is there anyone in chat who's not heard of good hooks before i can try to briefly explain what they are good hooks if you haven't cool um i'm glad so so have roger have you used git or like github before where you kind of understand like what it means to commit to push um things like that to pull code um you've heard of those keywords okay so when you think of each of those actions um let me show you okay so let me go to when you have get you have this dot get folder that appears um rarely will you ever need to go into the dot git folder but that's what i just did and then if we type ls there's a folder in here called hooks and so i'm going to cd in here to show you real quick now this is where your git hooks would go when you write them but if you don't have any you can actually look here and there's a bunch of samples um but let me just highlight a couple examples here so like there's a pre-commit that sample what this means is you can write like a script that will run right before you commit code and it's connected right to git so all you need to do is type git commit and this will run for you there's also like pre-push so you could say like before i push my code to github i want to run something this could be anything this could be like um you want to add a file that says something or like and i talked about earlier you want to automatically format code before you commit so that i don't have to consciously remember how to do it um there's a whole bunch of i don't actually know what all these are like i have no idea what fs monitor is um but it's just a way of seeing like you could um my battle fell uh you could write commits around a whole bunch of get actions uh so i like to add two that we're gonna talk about which one is like a pre-commit and one is like a pre-push um yeah exactly it's kind of just like that um so uh i'll show you the two that i like to write um now the way i'm gonna explain this one is uh it might be a little confusing but let me go back to projects here and figure out what our branch is uh it's number four oh this is not working because i need to go back to my actual project folder check out development get pull okay so we're going to do a new branch here okay so good hooks as a concept as i explained them uh you would basically create like a bash file and you would store it inside that docket directory that dot get slash hooks directory now i could make this segment of the stream really short by showing you my github and saving it there but i want to talk about like if i just do that the thing about that dot get directory is it's like it's private it's not committed so anything i put there it can't be shared with my team and if i want everyone to use the same get hooks that i do or at least in this project you know i want people who clone this project to use the same good hooks i do uh i want to be able to share them right so um i'm going to first show you how i create the get hooks i'm going to create a file store it in the repo and then we're going to go from there to show how i can take those files and store them in my docket directory using gradle and then all that we have to do is new members of the team will just clone the repo run the same gradle task and then they will also get the get hooks so let me show you the hooks first so i'm going to in my do i want to put this in build scripts no i'm going to make a new directory here i'm going to call it good hooks that's where i'm going to put them all so the first one we're going to do pre-commit the sh i'm going to copy code and then walk you through it so like i said i want to do a pre-commit hook where every time right before i commit my code i run k2 formatting so that's what this does uh i would check the repo if you want to follow this very closely but a lot of this code is confusing don't try to read it line by line let me talk you through what's happening the first thing i'm doing is getting rid of all of the changed files from our get diff that end in kts or kt because this only applies to our kotlin files right if there are none we say that we didn't change any kotlin files and we just exit otherwise we're running kt lit over these files and then we run the kt lint format gradle command over those changed files and then we go over each of those change files and now they've been changed we have to add them to git again so to get add the file that was changed and then we complete so this is going to run every time right before we commit code find the change katlin files format them let me know if you have any questions or you want me to explain like the uh defaults or like the details but then another thing i like to do is i like to do a pre-push so the difference between commit and push is like commit is just a way of like locally soaring your change but when you push is when your code actually goes to like github and so i want to say before my code goes to github i want to make sure that it's formatted which it should be already because of our pre-commit it is very mac linux centric if you want if you need help doing it for windows send me a message i'll see if i can help you out with that but this is definitely yes very like linux centric get hooks but i'm sure there's a way to write some scripting on windows to do the same thing but then i also want to run detect before i push so these are my two git hooks that i'd like to write but now we need to talk about well how do i get those git hooks into the directory where it matters so i'm going to um actually this next part roger is explicitly uh mac or linux um so i'm sorry for anyone watching this on windows uh it works great good hooks.gradle so the first thing i'm going to add to this whoops uh as i mentioned sebastiano from code with the italians is the one who helped me understand how to do this so i'm going to drop his blog post in chat um on githubs but let's talk about the steps to this so sebastiano recognized that this gradle task the way it was written only worked on linux or mac os so there's actually a check in this gradle test to make sure that the user is on linux or mac os otherwise it doesn't run it i would love to learn how to do this for windows but i don't i don't entirely know how to do this um let's talk about one gradle test so one of them is copy get hooks so the description of this task is that we copy github's from the github's folder into the dot get folder so the way this works is we say from this directory include any files that are star slash star.sh and it just renames it without the sh it basically removes the extension into the dot get slash hooks directory only if we're linux or mac os and then that's copying them is great but the other thing is by default that file is not runnable you need to modify it to make it runnable so that's what this next part install good hooks does so we get like this is an executable thing we get our working directory and so it runs chmod with this flag um on this directory and that basically says that everything in this directory can now be run otherwise without this task even if you put the file there by default on most machines you won't be allowed to run the github so let me show you this working um if i do an ls on the listing the files inside the gap that get slash hooks we see all of these uh sample files but if we look for the gradle task um somewhere where did you go where's the good hooks group oh it's because of the fact that i'm not applying this gradle file in the broader project um i need to do that so one second that's what i'm missing i'm just looking to remember how i did this um i need to go back into the have a good night tracks get some sleep go back in here this one is not about sub projects but the main project so we do apply from build script slash githubs.gradle so we need to actually apply that file and now we see now i see i have good hooks so if i run install get hooks um and i go back to turn with terminal and i do an ls we can see now that the pre-commit hook is there and the pre-push hook is there so this is really great now i have a way of sharing my good hooks all we need is for the other developers to clone and just run this task really cool but wait there's more so this is cool i don't have to like paste stuff into the folder and i don't have to like run the chmod command but it's still manual for me to clone the repo and like run this command but we can add this like trojan horse thing where like after evaluating our gradle we could do tests we can say the clean task we all run a gradle clean right depends on uh install githubs and what this will do is every time i run gradle clean it will install the get hooks now i know as matt pointed out when we were playing rocket league like every time seems like a lot but we're literally just talking about like moving files um it runs lightning fast right so it's not really slowing down you're clean but the nice thing is when someone clones your project all they need to do is write a clean and then they have your get hooks so i like this that means if any of you clone run this app uh you will get to see the get hooks so yeah that's that's good hooks that's how you can share them inside your repo and that's the two that i'm going to use for this project so let's make this last pull request and then we can call it a night oops number four and for those of you who hung around for the end i can uh show you a little sample of something cool that will come soon uh i actually i should have mentioned this beginning my family is visiting new york next week so next i'm going to be spending most of my evenings hanging out with them so i'm almost positive i won't be streaming next wednesday uh maybe i'll do something thursday or friday to make up for it but unfortunately i won't be around next wednesday um if that's allow us to ensure code is formatted uh before committing and pushing this will be another technique and this will go to developer experience yeah and i think that's everything i wanted to get through tonight um any thoughts questions concerns did i lose anyone was this interesting um did anyone learn anything new i know roger learned about git hooks um are there any of these tools that some of you might not have seen before i know like it's easy for me to think some of this stuff is standard but even if it is standard you know even if you've used danger maybe i gave you inspiration on a new way to use it um let's go look at the github project and make sure that everything is in place any open source projects that use danger almost all of mine uh but as far as any like popular android libraries or something i'm not sure um can't think of any but i know a few companies that use it all of the internal capsule repos use it just want to learn something outside your bubble what kind of text act do you usually work with roger or are you not in tech what do you do um yeah sorry i don't know if you finished that one web shark i don't i don't actually know about open source but like i use it on all of my projects um all of my companies like a lot of our internal repos use it it's been great well welcome to the community i'm really glad you could be here if you ever need any help getting started on android um feel free to ask me questions and chat or reach out to me on twitter stuff like that um always happy to help out cool i'm just giving this a second to finish running but then some nice danger checks yeah um i mean definitely check like let me pull up the api reference again so there's all the way at the bottom here there's an api reference uh one thing you can do is kind of skim this for ideas so they give you some examples uh whoops um there can i link to github can't but you can scroll down or like go to bitbucket or github whatever you use and i kind of just like to um [Music] what's the word um [Music] you can skim this and see like okay i can reference the title the body the author uh the branch for base the branch for head and once you see like the information you can reference you come up with unique ideas um you know like uh highlighting if this file has changed or the file hasn't changed make sure there's assignees um highlight when a celebrity makes a pull request uh yeah so like i i kind of skimmed this um to go through and list i don't want to put it on screen but i can show you some other ones i use at work real quick which are actually most of the ones that i included in the stream today but one that i didn't is um at my company we have a standard for uh the title of a pull request as well as the branch conventions so we have danger run a check to um make sure that the branch follows that idea oh i can show you another cool one web shark if you're still here uh on the old study guide project that we were working on before this one we had a danger at some point and this does a cool thing so i have a ticket to add it to this project but we didn't do it tonight there's a gradle plugin out there that will run through all of your dependencies and find out which ones has a new version and then it outputs that information into a text file and then i have danger read that text file and then check if there are updates and if it does it drops a message on the pull request telling me what is up to date so to see how that looks like if we look at like uh one of these it never got merged but um that looks like this so a bot will come in and say hey the following dependencies have later versions i could see like uh you know activity compose has a new version um and so on you know especially like sometimes it gets really large like if i highlight it like all of these are composed libraries so it's really like one version for me to bump but i get to see it for all of the dependencies so this one i didn't get to do it tonight but i'm glad you got to see it this is one of the unique implementations of danger um it can even tell you when there's a great overlease candidate so um another way to think about it is like anything you can do like in ruby which is effectively anything i would think that you would need to do um you can add as danger uh other ideas i've seen one team showed an idea where they compared like apk size so that uh danger would leave a comment if you were like changing the apk by too much or i've seen it leave a comment if your code coverage decreases um those are a little out of scope of what i wanted to do tonight but those are some more ideas um if you can think of ones for this project like i always invite people to leave issues if you think of something so like we could definitely make an issue or let me know and chat on twitter if you think of a cool danger check that would apply to this project um but this looks like it's working so i'm gonna close this out fixes number four um we will probably in a future stream do that versions thing if we look at the dev experience project i have two tickets i didn't want to put in tonight because we've been streaming for a while but i want to add code coverage of some kind i also want to add that version updates plugin and i'm sure we can take both of these and um words add them to danger but uh before i sign off um it's been kind of hidden but uh this guy right here this which opened on the other window um we have an app icon this is going to be the logo for the toa app um i also have like a little color palette to go with this um and i'm working on picking out some cool fonts the next stream whenever it may be whether i do it like in a couple days or whether it's in like a week and a half um we will be setting up the design system for the application so follow on twitch if you're not subscribe over on youtube follow me on twitter uh exclamation point twitter i'm gonna go do it um that's where you can find updates and you can see uh what we have in store in the future so wanted to give y'all a sneak peek at the app i cut but yeah thank you all for stopping by i had a ton of fun um i'm glad that plenty of people came to hang out even though we started late tonight uh but i think if there's nothing else anyone wants to talk about i am going to share the love and go raid one of my favorite esports streamers some of you have all seen me raid mclando before he is a pro rocket league coach i love watching him play rocket league i am going to send you all over to his chat so do hang out drop him a follow if you're interested in rocket league um i actually just realized i need to it's going to take like 10 seconds once i pick him but we are going to go over to mclandau so thanks again everyone we'll see you soon [Music] oh wait no i don't know i think i canceled it hold on don't leave don't leave we're gonna we're gonna do the rain i promise i don't know what i did wrong there we go all right now we're going over goodbye everyone how did your stream go what problems did we solve today i've looked in your stream before it's always interesting i always feel like i learned something even though it's probably not very applicable to my life i still feel like i learned something hi adam you get a shout out for adam please everybody give them a follow if you like programming at all i feel like you could learn a thing or two i mean i'm an idiot and i'm still like whoa that's cool hey zaylus and we got a song requesting doctor shout out adam i'll do it i got him boy him go follow the lad do it do it now

Channel: Adam McNeilly

Views: 306

Rating: 5 out of 5

Keywords:

Id: ePpbpLyYI1w

Length: 110min 4sec (6604 seconds)

Published: Thu Sep 09 2021