Podcasts about rails girls summer

In this week’s episode of Sustain Our Software the panel interviews Laura Gaetano. Laura is a developer and designer, whose main job was running was running Rails Girls Summer of Code. The panel considers how great Rails Girls is and all that they are doing. The panel also expresses their love for the Rails framework.    Laura explains the difference between Rails Girls and Rails Girls Summer of Code. The panel asks about the challenges that the Rails Girls Summer of code experience. Laura tells the panel how open source and the Ruby community has changed since they started. When they first started Rails Girls Summer of Code there was a lot less support for open source and diversity in programming. Now their main challenges are lack of resources, such as money and people who are invested in Rails Girls Summer of Code for the long term.    Other challenges in the organization stem from the nature of the organization. They are just trying to get everything done, that things like documentation and long term management solutions get forgotten. They want to get all their experience for the last six years documented so that knowledge can help in the future of Rails Girls Summer of Code.    The panel considers what a great feeling it is when people use or contribute to their open source and ask Laura what it’s like to actually help someone become a developer through her open source efforts. Laura explains how amazing it is to see women from past Rails Girls Summer of Code and their success. Laura shares her love of open source and the collaboration that happens in the community. Doing Rails Girls Summer of Code she gets a lot more human contact than in typical open source projects, she explains how that has made a difference in the way that she sees open source.    The panel asks Laura about the state of diversity in open source. Laura explains that there are initiatives out there to support diversity in opensource. She invites everyone to visit opensourcediversity.org. They provide resources to learn about diversity. They even have an open forum where people have a safe space to learn about diversity. She explains that diversity is now a common talking point at conferences to help improve diversity by educating developers about it. The panel discusses making projects more inclusive and explains how Github added s social impact feature that helps make your project more inclusive.    The topic turns to a talk Laura gave in 2017. Her talk explains that open source needs more than code. She explains that she would like to see more crowdsourcing of knowledge and design in open source. Programming is a major part of open source and she is so impressed the how willing programmers are to volunteer their time. However, she would love to see that desire from other people in the technology industry. Open source would be more maintainable if they had people marketing, networking, documenting. Having open source maintainers who focus on these things would help generate more funding and make it more sustainable.    The panel considers why there is such an emphasis on the code contributions, even more so than managing or other roles in open source. Code is a very visible contribution, easy to hold up and say look what they did. Other roles aren’t so easy to hold up, how can someone hold up the hours they spent finding sponsors or perfecting documentation.   The discussion turns to mental health in open source. Laura talks about her own state of mind and how hard it can be to get herself to do anything when she is feeling burnt out. She explains that she needs to change the way she approaches work.  The panel discusses ways that we can help those experiencing mental health problems in open source. They suggest talking to each other more about their experiences, about what depression, anxiety, and burn out look like and how they affect different people. The panel discusses what processes can be put in place to help developers to avoid burn out.    The panel wonders if developers are susceptible to mental health problems. Do the large workloads and high amounts of stress contribute to these issues. Laura explains that in her opinion, we as humans tend to think that our experience is unique, so other industries probably feel the same way. The reality is that this is a worldwide problem, especially for those that Laura calls knowledge workers.     The panel considers other ways we can help open source maintainers not get burnt out. The power of gratitude is one way they think might help. Laura thinks that getting a thank you from supports is very important. She relates how she feels when she talks with participants of Rails Girls Summer of Code and how it makes all her hard work worth it.   The panel discusses the power of money in open source, explaining why they started codefund. They explain the benefits of open source getting some money for their contributions. They consider the effect it plays on burn out. While Laura agrees to receive funds for open source contributions can be helpful, she warns that it could be a double-edged sword.   She warns that the receiving fund could be adding more stress to open source because of the responsibility it adds. Laura explains that she has already started to see entitlement from open source users, getting upset when the maintainer doesn't fix something right away. The panel considers how these benefits and costs when the funding is anonymous compared to when it is a direct sponsorship.   Panelists Eric Berry Nate Hopkins Guest Laura Gaetano Sponsors   DevEd Podcast The Freelancers Show My Ruby Story CacheFly Links AlterConf Berlin 2017: Making your voice heard: Open Source Needs You by Laura Gaetano Laura Gaetano - Building inclusive Open Source communities | ReasonConf 2018 https://devchat.tv/ruby-rogues/ https://railsgirlssummerofcode.org/  https://opensourcediversity.org/  https://www.codenewbie.org/podcast/rails-girls-summer-of-code  https://github.com/about/diversity  https://twitter.com/natfriedman/status/1157379019878232064  https://m.signalvnoise.com/to-smile-again/  https://twitter.com/alicetragedy https://github.com/alicetragedy https://www.facebook.com/Sustain-Our-Software-SOS-857471391289849/ https://twitter.com/sos_opensource Picks Eric Berry: https://webflow.com/  Nate Hopkins: https://www.metabase.com  Willow Hybrid Tree  Laura Gaetano: Jocelyn K. Glei  The Bulletin Design for Real Life

In this week’s episode of Sustain Our Software the panel interviews Laura Gaetano. Laura is a developer and designer, whose main job was running was running Rails Girls Summer of Code. The panel considers how great Rails Girls is and all that they are doing. The panel also expresses their love for the Rails framework.    Laura explains the difference between Rails Girls and Rails Girls Summer of Code. The panel asks about the challenges that the Rails Girls Summer of code experience. Laura tells the panel how open source and the Ruby community has changed since they started. When they first started Rails Girls Summer of Code there was a lot less support for open source and diversity in programming. Now their main challenges are lack of resources, such as money and people who are invested in Rails Girls Summer of Code for the long term.    Other challenges in the organization stem from the nature of the organization. They are just trying to get everything done, that things like documentation and long term management solutions get forgotten. They want to get all their experience for the last six years documented so that knowledge can help in the future of Rails Girls Summer of Code.    The panel considers what a great feeling it is when people use or contribute to their open source and ask Laura what it’s like to actually help someone become a developer through her open source efforts. Laura explains how amazing it is to see women from past Rails Girls Summer of Code and their success. Laura shares her love of open source and the collaboration that happens in the community. Doing Rails Girls Summer of Code she gets a lot more human contact than in typical open source projects, she explains how that has made a difference in the way that she sees open source.    The panel asks Laura about the state of diversity in open source. Laura explains that there are initiatives out there to support diversity in opensource. She invites everyone to visit opensourcediversity.org. They provide resources to learn about diversity. They even have an open forum where people have a safe space to learn about diversity. She explains that diversity is now a common talking point at conferences to help improve diversity by educating developers about it. The panel discusses making projects more inclusive and explains how Github added s social impact feature that helps make your project more inclusive.    The topic turns to a talk Laura gave in 2017. Her talk explains that open source needs more than code. She explains that she would like to see more crowdsourcing of knowledge and design in open source. Programming is a major part of open source and she is so impressed the how willing programmers are to volunteer their time. However, she would love to see that desire from other people in the technology industry. Open source would be more maintainable if they had people marketing, networking, documenting. Having open source maintainers who focus on these things would help generate more funding and make it more sustainable.    The panel considers why there is such an emphasis on the code contributions, even more so than managing or other roles in open source. Code is a very visible contribution, easy to hold up and say look what they did. Other roles aren’t so easy to hold up, how can someone hold up the hours they spent finding sponsors or perfecting documentation.   The discussion turns to mental health in open source. Laura talks about her own state of mind and how hard it can be to get herself to do anything when she is feeling burnt out. She explains that she needs to change the way she approaches work.  The panel discusses ways that we can help those experiencing mental health problems in open source. They suggest talking to each other more about their experiences, about what depression, anxiety, and burn out look like and how they affect different people. The panel discusses what processes can be put in place to help developers to avoid burn out.    The panel wonders if developers are susceptible to mental health problems. Do the large workloads and high amounts of stress contribute to these issues. Laura explains that in her opinion, we as humans tend to think that our experience is unique, so other industries probably feel the same way. The reality is that this is a worldwide problem, especially for those that Laura calls knowledge workers.     The panel considers other ways we can help open source maintainers not get burnt out. The power of gratitude is one way they think might help. Laura thinks that getting a thank you from supports is very important. She relates how she feels when she talks with participants of Rails Girls Summer of Code and how it makes all her hard work worth it.   The panel discusses the power of money in open source, explaining why they started codefund. They explain the benefits of open source getting some money for their contributions. They consider the effect it plays on burn out. While Laura agrees to receive funds for open source contributions can be helpful, she warns that it could be a double-edged sword.   She warns that the receiving fund could be adding more stress to open source because of the responsibility it adds. Laura explains that she has already started to see entitlement from open source users, getting upset when the maintainer doesn't fix something right away. The panel considers how these benefits and costs when the funding is anonymous compared to when it is a direct sponsorship.   Panelists Eric Berry Nate Hopkins Guest Laura Gaetano Sponsors   DevEd Podcast The Freelancers Show My Ruby Story CacheFly Links AlterConf Berlin 2017: Making your voice heard: Open Source Needs You by Laura Gaetano Laura Gaetano - Building inclusive Open Source communities | ReasonConf 2018 https://devchat.tv/ruby-rogues/ https://railsgirlssummerofcode.org/  https://opensourcediversity.org/  https://www.codenewbie.org/podcast/rails-girls-summer-of-code  https://github.com/about/diversity  https://twitter.com/natfriedman/status/1157379019878232064  https://m.signalvnoise.com/to-smile-again/  https://twitter.com/alicetragedy https://github.com/alicetragedy https://www.facebook.com/Sustain-Our-Software-SOS-857471391289849/ https://twitter.com/sos_opensource Picks Eric Berry: https://webflow.com/  Nate Hopkins: https://www.metabase.com  Willow Hybrid Tree  Laura Gaetano: Jocelyn K. Glei  The Bulletin Design for Real Life

In this week’s episode of Sustain Our Software the panel interviews Laura Gaetano. Laura is a developer and designer, whose main job was running was running Rails Girls Summer of Code. The panel considers how great Rails Girls is and all that they are doing. The panel also expresses their love for the Rails framework.  Laura explains the difference between Rails Girls and Rails Girls Summer of Code. The panel asks about the challenges that the Rails Girls Summer of code experience. Laura tells the panel how open source and the Ruby community has changed since they started. When they first started Rails Girls Summer of Code there was a lot less support for open source and diversity in programming. Now their main challenges are lack of resources, such as money and people who are invested in Rails Girls Summer of Code for the long term.  Other challenges in the organization stem from the nature of the organization. They are just trying to get everything done, that things like documentation and long term management solutions get forgotten. They want to get all their experience for the last six years documented so that knowledge can help in the future of Rails Girls Summer of Code.  The panel considers what a great feeling it is when people use or contribute to their open source and ask Laura what it’s like to actually help someone become a developer through her open source efforts. Laura explains how amazing it is to see women from past Rails Girls Summer of Code and their success. Laura shares her love of open source and the collaboration that happens in the community. Doing Rails Girls Summer of Code she gets a lot more human contact than in typical open source projects, she explains how that has made a difference in the way that she sees open source.  The panel asks Laura about the state of diversity in open source. Laura explains that there are initiatives out there to support diversity in opensource. She invites everyone to visit opensourcediversity.org. They provide resources to learn about diversity. They even have an open forum where people have a safe space to learn about diversity. She explains that diversity is now a common talking point at conferences to help improve diversity by educating developers about it. The panel discusses making projects more inclusive and explains how Github added s social impact feature that helps make your project more inclusive.  The topic turns to a talk Laura gave in 2017. Her talk explains that open source needs more than code. She explains that she would like to see more crowdsourcing of knowledge and design in open source. Programming is a major part of open source and she is so impressed the how willing programmers are to volunteer their time. However, she would love to see that desire from other people in the technology industry. Open source would be more maintainable if they had people marketing, networking, documenting. Having open source maintainers who focus on these things would help generate more funding and make it more sustainable.  The panel considers why there is such an emphasis on the code contributions, even more so than managing or other roles in open source. Code is a very visible contribution, easy to hold up and say look what they did. Other roles aren’t so easy to hold up, how can someone hold up the hours they spent finding sponsors or perfecting documentation. The discussion turns to mental health in open source. Laura talks about her own state of mind and how hard it can be to get herself to do anything when she is feeling burnt out. She explains that she needs to change the way she approaches work.  The panel discusses ways that we can help those experiencing mental health problems in open source. They suggest talking to each other more about their experiences, about what depression, anxiety, and burn out look like and how they affect different people. The panel discusses what processes can be put in place to help developers to avoid burn out.  The panel wonders if developers are susceptible to mental health problems. Do the large workloads and high amounts of stress contribute to these issues. Laura explains that in her opinion, we as humans tend to think that our experience is unique, so other industries probably feel the same way. The reality is that this is a worldwide problem, especially for those that Laura calls knowledge workers.   The panel considers other ways we can help open source maintainers not get burnt out. The power of gratitude is one way they think might help. Laura thinks that getting a thank you from supports is very important. She relates how she feels when she talks with participants of Rails Girls Summer of Code and how it makes all her hard work worth it. The panel discusses the power of money in open source, explaining why they started codefund. They explain the benefits of open source getting some money for their contributions. They consider the effect it plays on burn out. While Laura agrees to receive funds for open source contributions can be helpful, she warns that it could be a double-edged sword. She warns that the receiving fund could be adding more stress to open source because of the responsibility it adds. Laura explains that she has already started to see entitlement from open source users, getting upset when the maintainer doesn't fix something right away. The panel considers how these benefits and costs when the funding is anonymous compared to when it is a direct sponsorship.   Panelists Eric Berry Nate Hopkins Guest Laura Gaetano Sponsors   DevEd Podcast The Freelancers Show My Ruby Story CacheFly Links AlterConf Berlin 2017: Making your voice heard: Open Source Needs You by Laura Gaetano Laura Gaetano - Building inclusive Open Source communities | ReasonConf 2018 https://devchat.tv/ruby-rogues/ https://railsgirlssummerofcode.org/  https://opensourcediversity.org/  https://www.codenewbie.org/podcast/rails-girls-summer-of-code  https://github.com/about/diversity  https://twitter.com/natfriedman/status/1157379019878232064  https://m.signalvnoise.com/to-smile-again/  https://twitter.com/alicetragedy https://github.com/alicetragedy https://www.facebook.com/Sustain-Our-Software-SOS-857471391289849/ https://twitter.com/sos_opensource Picks Eric Berry: https://webflow.com/  Nate Hopkins: https://www.metabase.com  Willow Hybrid Tree  Laura Gaetano: Jocelyn K. Glei  The Bulletin Design for Real Life Special Guest: Laura Gaetano.

Show Notes Springfestival (https://springfestival.at/) Rails Girls (http://railsgirls.com) Dom im Berg (https://www.telegraph.co.uk/travel/galleries/worlds-coolest-underground-attractions/dom-im-berg--graz--austria/) Moderat (https://moderat.fm/) Deadmau5 Studio Tour (https://www.youtube.com/watch?v=dBiqFNNfudA) Kraftwerk (https://en.wikipedia.org/wiki/Kraftwerk) Floor Drees (https://twitter.com/FloorDrees) ROSS conf (https://www.rossconf.io/) Rayta van Rijswijk (https://www.parallelpassion.com/9) Piotr Szotkowski (https://www.parallelpassion.com/14) EuRuKo 2019 (https://euruko2019.org/) Rails Girls Summer of Code (https://railsgirlssummerofcode.org/) Facebook pays teens to install VPN that spies on them (https://techcrunch.com/2019/01/29/facebook-project-atlas/) Zuckerberg Plans to Integrate WhatsApp, Instagram and Facebook Messenger (https://www.nytimes.com/2019/01/25/technology/facebook-instagram-whatsapp-messenger.html) Spotify to acquire Gimlet and Anchor (https://investors.spotify.com/financials/press-release-details/2019/Spotify-Announces-Strategic-Acquisitions-to-Accelerate-Growth-in-Podcasting/default.aspx) Signal (https://signal.org/) Solid (https://solid.mit.edu/) diaspora* (https://diasporafoundation.org/) Mastodon (https://joinmastodon.org/) Your Apps Know Where You Were Last Night, and They’re Not Keeping It Secret (https://www.nytimes.com/interactive/2018/12/10/business/location-data-privacy-apps.html) You (https://www.netflix.com/si/title/80211991) Recommendations The Subtle Art of Not Giving a F*ck (https://www.amazon.com/o/ASIN/0062457713/parpaspod-20) Time Well Spent (https://www.youtube.com/watch?v=tf9ZhU7zF8s) The National (https://en.wikipedia.org/wiki/The_National_(band)) Sebastian Gräßl Twitter (https://twitter.com/bastilian) Instagram (https://instagram.com/bastilian) SoundCloud (https://soundcloud.com/bastilian) Personal Page (https://bastilian.me/) Parallel Passion Patreon (https://www.patreon.com/parpaspod) Twitter (https://www.twitter.com/parpaspod) Instagram (https://www.instagram.com/parpaspod) Facebook (https://www.facebook.com/parpaspod) Credits James Owen (https://unsplash.com/@jhjowen) for the header photo Tina Tavčar (https://twitter.com/tinatavcar) for Parallel Passion logo Jan Jenko (https://twitter.com/JanJenko) for intro/outro music

We talk with Saskia Lindner about her experience working on re-frame-10x in Rails Girls Summer of Code, ClojureBridge, remote working, and compassionate coding.. ClojureBridge Talk at ClojureD on re-frame-10x re-frame-10x Saskia and Chris’ dev journal Rails Girls Summer of Code Full stack developer job at Zimpler

Show Notes Breaker (https://www.breaker.audio/) Ruby Heroes 2014 (https://rubyheroes.com/heroes/2014) Rails Girls Summer of Code (https://railsgirlssummerofcode.org/) RailsAdmin (https://github.com/sferik/rails_admin) Soundclouders pronouncing shoe brands (https://soundcloud.com/erik/tracks) Becoming Berlins (https://dianaberlin.com/posts/becoming-berlins) Breaker Upstream on Product Hunt (https://www.producthunt.com/posts/breaker-upstream) The Menu Bar: We Should Always Be Afraid, With Marco Arment (http://www.themenu.bar/show/2018/10/7/the-menu-bar-episode-26-we-should-always-be-afraid-with-marco-arment) Serial Podcast (https://serialpodcast.org/) xkcd: Someone Is Wrong on the Internet (https://xkcd.com/386/) Recommendations Elektra Microcasa Semi Automatica (http://www.elektrasrl.com/en/espresso-coffee-maker/microcasasemiautomatica-sx/) Acaia Lunar (https://acaia.co/products/lunar) Hidden Brain (https://www.npr.org/podcasts/510308/hidden-brain) Reply All (https://www.gimletmedia.com/reply-all) 99% Invisible (https://99percentinvisible.org/) Revisionist History (http://revisionisthistory.com/) You Are Not So Smart (https://youarenotsosmart.com/) Everything Is Alive (https://www.everythingisalive.com/) Erik Berlin Twitter (https://twitter.com/sferik) Breaker (https://www.breaker.audio/) Parallel Passion Patreon (https://www.patreon.com/parpaspod) Twitter (https://www.twitter.com/parpaspod) Instagram (https://www.instagram.com/parpaspod) Facebook (https://www.facebook.com/parpaspod) Credits Tina Tavčar (https://twitter.com/tinatavcar) for the logo Jan Jenko (https://twitter.com/JanJenko) for the music

Show Notes Hello Ruby (https://www.helloruby.com/) Rails Girls (http://railsgirls.com/) Karri Saarinen (https://karrisaarinen.com/) Ruby Heroes 2013 (https://rubyheroes.com/heroes/2013) Rails Girls Summer of Code (https://railsgirlssummerofcode.org/) Codecademy (https://www.codecademy.com/) Hello Ruby Kickstarter (https://www.kickstarter.com/projects/lindaliukas/hello-ruby) Hello Ruby: Expedition to the Internet (https://www.amazon.com/o/ASIN/1250195993/parpaspod-20) Bubble Sort Zines (https://shop.bubblesort.io/) TED Talk: A delightful way to teach kids about computers (https://www.ted.com/talks/linda_liukas_a_delightful_way_to_teach_kids_about_computers) Eat and Run: My Unlikely Journey to Ultramarathon Greatness (https://www.amazon.com/o/ASIN/0544002318/parpaspod-20) Footnotes: How Running Makes Us Human (https://www.amazon.com/o/ASIN/1250127246/parpaspod-20) What I Talk About When I Talk About Running (https://www.amazon.com/o/ASIN/0099526158/parpaspod-20) Recommendations Follow your curiosity Seeing Is Forgetting the Name of the Thing One Sees (https://www.amazon.com/o/ASIN/0520256093/parpaspod-20) Björk (https://en.wikipedia.org/wiki/Bj%C3%B6rk) Linda Liukas Personal Page (http://lindaliukas.com/) Twitter (https://twitter.com/lindaliukas) Instagram (https://www.instagram.com/lindaliukas) Parallel Passion Patreon (https://www.patreon.com/parpaspod) Twitter (https://www.twitter.com/parpaspod) Instagram (https://www.instagram.com/parpaspod) Facebook (https://www.facebook.com/parpaspod) Credits Tina Tavčar (https://twitter.com/tinatavcar) for the logo Jan Jenko (https://twitter.com/JanJenko) for the music

Special Guests: Brian Douglas and Bex Warner of GitHub. In this episode, the panelists talk about automating GitHub with Probot. The origins of Probot are discussed, as well as making GitHub apps with the GitHub API, automating workflows with Probot, must-have Probots for every repo, and GitHub's V4 GraphQL API. References: Microstates README Probot github.com/integrations/slack github.com/marketplace/pull-reminders platform.github.community/c/integrations probot.github.io/apps/unfurl-links/ probot.github.io/docs/deployment/ probot.github.io/docs/extensions/#scheduler probot.github.io/community This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC. TRANSCRIPT: ROBERT: Hello everyone and welcome to Episode 105 of The Frontside Podcast. I'm Robert DeLuca, the director of open source here at the Frontside and I'll be your episode host. Today, we're going to be discussing automating GitHub with Probot with Brian Douglas and Bex Warner. I'm really excited about this topic. The idea of automating GitHub workflows with bots is amazing. This is something that I've been wishing the GitHub have the platform support for since I even started using GitHub for open source. Just being able to have a bot to take care of certain things like somebody doesn't leave enough of a PR description and they open up a PR, you can have a bot that just responds to it and saying, "Can you provide more information?" It's pretty awesome. With me as co-host today is Charles Lowell, who is also a developer here at the Frontside. Hey, Charles. CHARLES: Hey, Robert. ROBERT: Before we get into the discussion, I like to make a tiny little announcement. We've been building a composable and an immutable state container called Microstates. I'm sure Charles can talk about this more at length, then we will in the next podcast episode -- 106, but I would like to make a small announcement that Taras who is an awesome developer here just wrapped up a month's worth of work, creating a new ReadMe to describe the vision of Microstates and what you can do with them and everything about Microstates. If you're interested in that, I highly recommend checking out the ReadMe. I'll drop a link in the show notes for you that are interested. CHARLES: If I can add, it really is [inaudible] because it isn't like any other state management solution out there. ROBERT: No, absolutely not. I've been building something with it in React Native over the weekend of the 4th of July and it's amazing. But enough about that, you'll hear about that next episode. For this episode, I want to talk about Probot with Brian and Bex. Hi are you two doing? BRIAN: I'm well. BEX: I'm good. Thanks for having us. ROBERT: No, thank you for joining. This is really exciting. Like I said in the intro, I've been really excited about this project. I do a good amount of open source, I would say and this has been really helpful in all of our repos. We have, I think like 78 open source repos on the Frontside. We have Microstates, like we just talked about and Big Test and all of those repos use some combination of Probots that people have built and it's really nice, especially with the new Checks API that has just come out. You can integrate Probot into that, right? BEX: Yes. I, actually am currently working on shifting one of our bots from using the commits Statuses API to the Checks API. ROBERT: That's awesome. Before we go too deep into it because I want to come back to that because that sounds really cool and what the integration of that is like and what changes because I'm not even really that familiar with it. I just know it was released. I kind of want to go from the beginning here. Where did Probot come from and can we get a little bit of a history for everybody that might not know what Probot is? BEX: Sure. Probot originally started out as this simple idea to make GitHub scriptable. The original idea was you have a single file in your repository that would be like a JavaScript file and it would essentially spell out how the bot would act on your repository and the goal was to make GitHub apps accessible to people because if you ever look through our GitHub apps documentation, I think it can be a little tough to get started. There's, honestly, a lot of nonsense that you have to go through in order to get set up. For one thing, the way our GitHub app authentication works is it requires a JSON web token followed by using that JSON web token to request an installation access token and that process would be really tough for new people to get started. ROBERT: Yeah, it sounds like it. BEX: Yeah, so Probot was created to abstract all of that away and handle all of that authentication automatically and simply leave you with the payload that you get from listening on web token events and in authenticated GitHub client to make authenticated API requests while authenticating as an app. ROBERT: Cool, so that's where it started like a flat JavaScript file in the root but today, you use like EMO files and a .GitHub folder. How do that kind of progress? BEX: Originally, their use case was much simpler and it quickly became clear that a single JavaScript file in the GitHub repo was not scriptable enough and not easy enough to understand. The goal was to make like an API that could make that JavaScript file really, really easy to customize for every API of GitHub and it quickly became clear that that was not really a feasible thing to do. as time went on, it turned into this way to build Node JS applications and essentially, what the configuration files you're referring to are the way in which we make it customizable because right now, there's no way to be officially supported GitHub apps channels to pass secrets because it means you're a [inaudible] and the owners of GitHub apps, so that was just a way to kind of stop that problem. ROBERT: Gotcha, okay. BEX: The actual code for GitHub apps still lives in a Node JS module basically and the configuration file just specifies how that module runs. ROBERT: Right, so they're deployed like Heroku instances, if you want, like anywhere you can host a node app. BEX: Yup. Heroku, Now, yeah. ROBERT: Interesting. BRIAN: As a reason to that, some explorations of doing serverless deployments for Probot, I think there's a couple of issues of them. I'm not sure if anybody's shipped anything like the way they at but it's pretty much it's possible to. BEX: Just a week ago, we even released a new version in which we update our core from Node JS to TypeScript and now that things are typed, we have big plans for serverless. ROBERT: Nice. That's awesome, so then you'll be able to deploy to a Lambda and off to [inaudible]. BEX: Exactly. CHARLES: Can I actually interject here, as kind of a person who doesn't really know the relationship between GitHub apps and the GitHub marketplace and what exactly a Probot is before we hear the origin story. I would love to hear a very high level view of how this ecosystem fits together. BRIAN: I think a lot of people are pretty familiar with interacting with the GitHub API and OAuth integrations. I think I've just spent a lot of time at different companies previously to GitHub, just like making calls, either to cURL or through Node JS or more recently, [inaudible]. GitHub apps itself are a way to take all the things that you had to do to make an integration to GitHub much easier. It has a lot of cool things like OAuth, scopings, so you no longer have ask for all your repos ask access whenever someone logs in with GitHub and the connection between like, "Now have gone from OAuth to Now to GitHub apps," there was a lot of, as Bex mentioned earlier, ceremony that happens to getting set up with GitHub apps and integrations that Probot is like this tool to speed up the process of getting to the point where you just want to script some automation or some sort of workflow and it gives you all that bullet play for you. I don't know if that was a good high level for you Charles. CHARLES: Yeah. I've kind of witnessed this second hand with Robert installing a bunch of things here, so let's use an example, like you did some sort of automation on our repos, Robert, where when someone files a ticket, there's this workflow that automatically adds a triage label, so that we know that this thing hasn't even been dealt with, so we really need to address that issue. It doesn't need to be as a high priority. It doesn't need to be closed as a duplicate of something. One of the different aspects that you described there, how do they fit in terms of serving this workflow onto the end user? Or was that a good example, even? BRIAN: One of the cool thing about GitHub apps and what Probot does for you is that normally, if you want to add a label to an issue, either you Charles or Robert, would have to be admin or maintainer on the team for the Frontside and you could add labels. But somebody who opens up an issue, doesn't have that ability to have write access to your content, which is adding a label. What a GitHub app does, it actually takes a spot as if you would have another user on your platform, instead of creating a dummy account or a dummy user. Probot is basically building a bot for you to then, give you the ability to add that issue. That's sort of workflow that normally would have to happen through an actual real human could not happen through a bot without taking up a spot of like, "I guess, I probably shouldn't speak so ignorant about our platform and what we actually pay for nowadays for GitHub," but I know we used to have like a limited amount of seats for organization, like that seat no longer has now taken up and now, it could be just be used a bot can do something that normally us would take. ROBERT: Right. You no longer have to create a user to do these things. BRIAN: Correct. BEX: [inaudible] within GitHub. It's sort of built in a way that apps can take a lot of power in your repositories. CHARLES: So then, what is the relationship between Probot and an app? BEX: Probot is essentially the framework for building an app. You can definitely make the equivalent of any Probot app outside of Probot. It abstracts away all of, basically, the horrible parts and leave the easy part. CHARLES: Now, I think I'm ready to participate in this discussion. ROBERT: That was perfect, though. That's a great intro because I actually didn't have a total grasp or understanding of the relationship between GitHub apps and Probots. That's really good. BEX: Yeah. Additionally, going back a second. You mentioned the marketplace before. One thing to note that is that there actually are several Probot apps on the marketplace right now. The marketplace is essentially the home for any larger, usually third-party companies that have made apps and Probot is essentially supporting some of those. ROBERT: Interesting, so then my question would then be, do you know anybody selling their Probots. Does the marketplace charge? I'm going to assume it does. BEX: Yes. ROBERT: Okay. Is there anybody charging for their Probot? BEX: Yes. There is a quite a few, in-fact, charging for it. Recently, a pretty popular example is the GitHub Slack integration, which is if you open new issues, you can have them appear in your Slack channel. That whole application was recently rewritten by GitHub. It was previously owned by Slack and that was built on top of Probot. CHARLES: And I actually remember, we upgraded to that version. It's actually way, way, way better. BEX: I'm glad you feel that way. CHARLES: I didn't know the story behind there. I was like, "Oh, I just got a lot of... Awesome," you know? Although I don't know what's the costing. BEX: Yeah, I think that integration is actually free, so that wasn't the best example. I think it's for open source projects, at the very least. BRIAN: Brandon, one of the maintainers for the Slack integration and work at GitHub, also did a really cool talk at the SlackDev Conference a couple of weeks ago, so if you're interested what were the behind the scenes. That integration is all open source as well, so if you have request or you have features that you would like to add to the Slack integration, you can pop into the repo that hopefully will show up on the show notes because I'm not sure if it's like GitHub/Slack, but I guess we'll find that out in the show notes later on. BEX: It's Integration/Slack. BRIAN: But for an example of a paid app of a non-third party, we're not talking like Travis or Circle or another one with the big names but rather, a solo dev created. It's Pull Reminders, which is on the marketplace as of today and essentially, this gives you reminders of your pull quest, so you can actually ping inside the comments and tell Pull Reminders to say, "Tell me about the pull request like next week because it's Friday and I don't have time to look at this." ROBERT: That's awesome. I've also seen the one that's kind of related, that is like you can set your out of office at GitHub, which is actually kind of a neat concept. BEX: Was that the one where we are already changing that profile photos to have the overlay or the one where is just auto-replying to messages because I've seen a couple of -- ROBERT: I think, it's just auto-replies. BEX: Okay. CHARLES: So, it can change like your profile pictures and really, not just related to repo and history related activities but everything? BEX: Anything that you can access via the GitHub API, you can almost access via GitHub apps. There's a list of end points that I specifically enable for GitHub apps because there's something such as delete a repository that there's basically, a very few circumstances under which you want to give that permission to an app. Also, to things very specific like your profile or your personal page. About a year ago, there was an official internal audit of all of the API endpoints because there are lots of inconsistencies over what was and what wasn't enabled for GitHub apps, so they went there and kind of decided, what endpoints should be enabled and what endpoints actually get enabled. Now, that list is much longer than it was a year ago. Now, it's much more comprehensive. ROBERT: That's awesome and is this for the Rest API and the GraphQL API? BEX: Yes. Probot does support both. The Rest API is the one that specifically had all of these endpoints audited. The GraphQL, since it's a bit newer, we sort of built those and more. ROBERT: Cool. I really like working with the GraphQL API with GitHub. It makes it easier than trying to do a bunch of Rest calls. BRIAN: Yeah, there's a community form, it's like a discourse form that the API team actually manages and sort of pipes in there. Again, going back to like, if there's not something in the Slack integration that you would like to have, the form, that community is actually in there, if there's something not in the GraphQL API, that you would like to see. No promises on shipping it within an x amount of time but if enough people are requesting it obviously, there's going to be some resources [inaudible] at. ROBERT: What do you mean? We're doing open source. It has to be done yesterday. BRIAN: Yeah, exactly. And that form is at Platform.GitHub.Community, just a URL to get there. ROBERT: Awesome, that will be helpful to look through and get some recommendations in there. One of my favorite things I was going to say about the new integration for Slack and GitHub is the fact that I can highlight line numbers, paste that linked in and then it just expands it and the chat in Slack. That is so nice and I use it all the time. BEX: Yeah, I love that they built that feature. Actually, the original feature that was built on GitHub to allow those line expansions in the first place, like on GitHub itself, was actually built last summer by some folks who were also a part of my intern class at GitHub last year. ROBERT: Hey, intern power. That's awesome. BEX: Yeah. ROBERT: Everyone there is doing amazing work. I'm also following along with somebody that is also an intern and it's building a weekly digest program. BEX: Oh, yeah. That's actually a Google Summer of Code student. ROBERT: Oh, interesting. BEX: So, being sponsored through Google Summer of Code by Probot as an open source support. ROBERT: Is there anything more to unpack there? That sounds really interesting. BEX: Essentially, we submitted an application for Google Summer of Code because we thought it'd be a cool way to get more people, more students, a mentorship opportunity for the maintainers, basically and we were honestly overwhelmed. We got like almost 100 applications and it ended up being a huge of a deal but we're -- ROBERT: That's a great problem. BEX: Yeah, definitely a good problem but we were really happy. We, initially wanted to accept more students but Google limited us to only two students, so we have two Google Summer of Code students working on projects and one team of women from Rails Girls Summer of Code working on Probot. ROBERT: That would be awesome. What do they working on? BEX: I'm not sure yet. They actually just started a couple of days ago but the other Google Summer of Code student is working on a background checks API to eventually do sentiment analysis of comment history of someone new to your repository. ROBERT: That's interesting. That sounds like there will be some machine learning in there. I might just throwing out buzzwords? BEX: Most likely, I think they're just using some sentiment analysis API, like the perspective API. I don't think they're actually doing that themselves. ROBERT: Okay. CHARLES: Actually, I have a couple questions. Back on the subject of Probot. How does this square with the classic mode of integration because there was a lot out there? I think the first one that I remember that stuck in my mind was like Travis and I don't know if there had to be like a special relationship between the Travis developers and the GitHub developers, that's like, they was able to make that integration happen so many years ago. I don't know how that happened. I just remember it popped up and I was like, "Woah. This is incredible," and we see kind of the integrations gets more and more rich. For someone who's got, like you mentioned a couple of the big names, is the idea that eventually those would be able to be completely supported is GitHub apps or is it they're always going to be kind of a separate track for kind of the really deep integrations? BRIAN: I wasn't around when Travis first integrated with Lyft GitHub and I think that's a really cool integration and I know they have a very nice sized team that's able to do that. I think if we zoom back out like Probot, the way to get started with Probot is that we have the CLI command, which is to create Probot app. I believe it was intentionally copied off of create React app and the cool thing about create React app and create Probot app is that they abstract all the ceremony and boilerplate to get started really quickly. It was like, what developers or smaller teams can get started with integrating with GitHub apps. I highly doubt that Travis is going to rewrite their entire application with something like create Probot app but they're definitely going to be moving towards the new API calls, which would have been like GitHub apps. Part of the Checks API that we had launched at the end of May, Travis had blog post on how their integration with the Checks API works. They're making, though they have a lot of what Legacy endpoints and a lot of Legacy integrations in the way they integrate with GitHub, they are actively moving towards a GitHub app. I don't know if I could actually comment on their status of where they are today, to be honest but actively, we want all new apps and new integrations to follow the model of being a GitHub app, so that way, out of the box, you have access to all the newer features. You have all the access to all the newer GraphQL endpoints, if you want to use GraphQL and that way, we can serve one market, as opposed to everybody who had a GitHub integration from five or six years ago, that was all piecemeal together and sort of duct tape, like we run move away from duct tape everything together. CHARLES: I see. BEX: I definitely agree that I don't think Travis is going to switch to using Probot anytime soon and I don't think most of the large companies will be doing that but I do think, there will be shift towards GitHub apps in general. For those companies that don't already have the buildings of the GitHub app started, I think that Probot could be, in time to free some of them. BRIAN: In addition to that too, Travis and Circle and all the CI integrations, they're doing a really good job. I think the cool thing about GitHub apps is what you take away all that ceremony of getting your checks to work, now we can start opening up the door of like what's the next sort of CICD thing like? There's another term or another, I guess category of applications that can now be built to improve GitHub. CHARLES: The most amazing thing about having a great platform is the apps that you don't foresee, like it just come completely out of left field and you're like, "Woah. I can't believe that's actually a possibility now." When you have started to see some of those, some Probot or GitHub apps, you're like, "Man, I didn't see that coming. That's awesome." BEX: A hundred percent. I think it's the most exciting part of Probot because I think GitHub as a platform, we all know GitHub is the largest developer platform in the world and I think the idea that developers can build on top of this platform is the most exciting idea right now. I have honestly already seen apps that really excites me. The other day, I saw this app that was definitely not near completion but it was essentially updating and issue a comment box over and over and taking response through like checking a box and then listening on that common edit, in order to specify your coffee order. ROBERT: Woah. BEX: I was like, "Do you want an ice coffee or regular? Do you want milk or sugar and cream?" and it was going one at a time. It didn't actually order you your coffee at the end but it was super exciting to watch that. You're just editing the comment. I had never seen that before. ROBERT: That's pretty slick and that's taking the API pretty far. I'm sure there were some parsing in there and each Webhook response are like, "Was this box edited or not." That interesting. CHARLES: Yeah. Actually, now that we're having this discussion is kind of like changing my mind a little bit. Robert and I were actually talking yesterday about trying to standardize on our release management and our plan was basically to have some software that was going to run inside of our CI provider and have kind of a shared library, just a little ntm package that was shared by all of our repos but I'm thinking now, man, we should really explore doing this as a GitHub app. ROBERT: Yes, please. I've had three ideas that I really want to build out as a Probot. I'm just going to list them off and then we can build them all together and take equity and you know. I'm kidding. But the two that really excite me, that I kind of want to do is one concept that we work on this open source project for our clients and if somebody from the outside that doesn't have commit bits to be able to push to master, it would be really cool if we had a Probot that after it had an approved on the PR, from the maintainer, that the person that open the PR could then tell a Probot say, "This is approved by somebody that manages this project. Can we merge?" and then the Probot would then actually merge. I don't know if that's possible. That's something that I definitely wanted to explore. Then the other one, which is less cool, would just be like if we have a couple branches on some of our projects that we want to continue and we're not ready to put it back into master but we want to continuously run the test suite against it, so the idea there would be to have a Probot that would watch for changes on master and rebase as needed and continue to run the test suite and see where you're at. Those are the two things that I'm really excited about to do with Probot but I just want to automate everything with GitHub now. CHARLES: Right. BEX: Yeah, definitely, that first idea was actually pretty viable. I'm curious to know like how you actually get those commit links -- is that what you called it? ROBERT: Commit bits are more like commit permissions, I guess. BEX: Oh, I see. ROBERT: An outside contributor. CHARLES: Yeah, we want to push responsibility to the person who is the maintainer who can approve it but actually, the way we do it at Frontside is the person who actually is making the change is responsible for merging it. Once you get approval, you still have to hit the go button and that's just going to make sure that you're taking responsibility for saying it's done but that doesn't work for open source because people coming off the internet are going to have the right to push but we would like to give it to them, maybe via an app, if there is a maintainer who's approved it. BEX: Yeah. That's definitely something you can do. I've seen quite a few apps that, essentially add outside collaborators to the repo. Are you familiar with the... I forgot what it is called, like the all contributor section, where you cite everyone in your repo and everything and who's worked on it. There was a GitHub app that would add someone automatically after they merge their first change. CHARLES: That's awesome. ROBERT: I may have seen that on React State Museum but I'm not sure. It's a repo that we've contributed to and it has all the contributors at the bottom. It seemingly just kind of popped up there. BRIAN: There's an app that, I would like to mention too that I'm pretty excited about, that it sounds trivial too and it's almost similar... Not similar but it's sort of related to what you were talking about, Rob, with your first app, which is the WIP bot, which is the work-in-progress bot. This is a pattern of whenever I open a PR and I might not ready for a merge but I want to share my code so I can get feedback earlier on, I'll type in WIP so that append to my title of my PR. What this engineer did was every time you do WIP, it's going to go into the GitHub API and actually block the PR for merging, which is a feature available to GitHub. It's nested in your settings but the cool thing about this it actually blocks the PR for merging, so you don't have to worry about getting your, sort of like show and tell code merging the master without being ready. ROBERT: That's one of the first bots that I installed on all of our repos and then you can correct me if I'm wrong, it didn't always have the ability to block the PR from being merged but with the new Checks API, is that something that was introduced? BEX: Not exactly. The way that blocking of merging works is if you set it as the required status, so you can install any sort of CI on your account and have it not being required and ignore it whenever you feel like it, so it's really up to you to make it required. Otherwise, it just isn't checked and that's true for anyone who uses the Statuses or the Checks API. ROBERT: Okay, so that's a Statuses API. Okay, sorry. BEX: Yes. ROBERT: Also, the cool thing about that that I noticed when that was rolled out was I was now able to pick and choose and use workflows on Circle CI and each workflow is broken out as a different status check. I am now required like linting and the build and the test have to pass for these browsers before it can merge, which is really cool to be able to pick and choose. BEX: Yeah. It's awesome. I know personally on some of my repos, I have a few checks that I just don't require because I know I have to make them pass. ROBERT: Yeah. Speaking specifically about the work-in-progress bot, do you know how that works? It's open source, so I am sure I can go look. I think we want to go make a PR. We had some back and forth about this, Charles. CHARLES: I actually just [inaudible] we disagree. ROBERT: Yes. Charles opened a PR and one of his first commits in the PR had work in progress and the title had work in progress and we have this this Probot on our website and it was a blog post. You know, you make a couple more commits and you're further down, you move the work in progress in the title but the PR were still blocked because the first commit on a PR have work in progress in it. I think if it's the most recent commit or if it's in your PR title with work in progress, it should block but otherwise, it should not and Charles feels differently. CHARLES: I have about six commits and the very first one have WIP in the title or in the commit message and it blocked the whole thing but I kind of felt like it actually made me go back and I had to squash it down to two commits because I actually feel that your commit history should tell the story of the development, not like it should an absolute one-to-one journal of what happens but what you are intending. I actually felt that it could help me out because there's six commits that we're kind of all over the place and just kind of slapdash together have made me kind of go back, rethink it and tell a coherent story. I think it did me a service but it was not obvious. I definitely agree with that but I was like, "Why? Why were you still blocking?" ROBERT: Do I really [inaudible] admin privileges? BEX: I would say, I am friends with the creator of the web app. His name is Gregory Mantis and he is actually got a huge work in progress PR shifting work in progress over to using the Checks API and one of the features that he's using with the Checks API is essentially this mark as now work in progress button that will add the special line, like feel free to merge or something like that into your original PR description at the bottom. If that is there, the work in progress app will no longer be blocking. It's essentially like a hard override and honestly, that's the power at the Checks API versus the Statuses API. That's really exciting. ROBERT: Because I have seen the work in progress bot to get into a weird state, where I did remove the work in progress from the title but it didn't quite update and I'm still blocked. It's okay for me because I have admin privileges but other people on the team maybe not and they might be blocked from something that's actually work in progress. It's a lot like that hard override will be probably pretty helpful. BEX: Yeah, definitely. I think sometimes, there's some confusion with that just because of the way what perks work on GitHub and the way our pages are rendered, that you may need to refresh the page before you actually see it take effect. ROBERT: Right, yeah. Overall though, I love that bot. I go weekly, probably to the Probot apps listing and just go shopping. BEX: Wow. I'm actually the person who approves all the Probot apps to the listings so that's pretty motivating there. ROBERT: It's really nice. I am not even joking when I say shopping, I go through and I open up a bunch of tabs, I read through them, "Oh, this could be useful," that kind of thing. BEX: The first app you mentioned, which was like the one that requests more info is actually one that I built, so that was kind of funny. I guess you got that from the Probot apps too. ROBERT: Yup. That one, we definitely use on a couple of our organizations and repos. It has yelled at me a couple of times because of a blank PR. BEX: It yells at me all the time. I think I get yelled at more than people who are actually doing it wrong. ROBERT: I'm a little embarrassed like, "I should do better. I need to set an example." BEX: Definitely. ROBERT: Cool. I'm curious what both of your favorite Probot app is. This ought to be interesting. BRIAN: The app that I'm really impressed with so far, that I actually only use on a junk project at the moment, is the weekly digest one and it's mainly because I built something for this in my previous role at the company but then we shift it, which is basically go through every single repo. I worked at a company called Netlify previously and we had way too many repos to maintain... Oh, sorry, to keep track of and I was moving further and further away from the backend at the time so I was unable to keep up to date with all that was changing. I built a Lambda to watch Webhooks and then give me a digest of what was shipped like issues and PRs closed. It was way over-engineered and I never actually shipped that to actually make it work. But then the weekly digesting came out maybe a couple of weeks ago and it blew me away because I was like, "This is exactly what I needed," and I was trying to make it overly complicated through like a Lambda and like a bunch of Webhooks and this person, with only a few weeks, has the scaffolding of what I needed. That's the one thing I'm pretty excited about. It was already mentioned earlier too, as well. BEX: I guess, I would say one of my favorite ones is the unfurl a link app. I think that one it so simple but so nice. I don't know. I think having that unfurl link preview is just beautiful. Essentially what it does is it listens on issue comment creation or pull request comment creation or issues your pull request or whatever and read through the text or whatever was that issue or pull request and looks for links and then, essentially unfurls them so you can get a really nice preview of what you're going to. I think that's really beautiful and just so simple. ROBERT: Yeah. I love that one too. I have that added to all of our repos. BEX: It's so much nicer. Why would you not unfurl your links when you could unfurl your links? ROBERT: Exactly. CHARLES: I actually have a question. I think it's been touched on, probably at least twice throughout the conversation. I want to actually create a Probot, how do I actually go about deploying it? What does that look like? What does it look like to deploy and maintain it? BEX: We have a page on our docs about deployment and essentially the TL;DR is you can deploy it on any normal cloud hosting service that you wanted to deploy it. There are a few things you need to specify. For example, GitHub gives you a private key that you need to create your JWT and that private key means to be passed into your hosting service however you do that and then, there's a few bits of information that need to be pass in. We have pretty intense docs about it. Honestly, I'm not a deployment person. I usually try to let other people do that and I have never had a problem going through our docs and just getting it working immediately. BRIAN: It's also mentioned that there are examples like Heroku and Now and a couple of other ones. If you have a service that you already like, it's possible it's already in the docs, like steps to how to get that deployed. BEX: Yup and any other services are more than welcome to be added to the docs. Pull request are welcome. ROBERT: Sweet. It sounds like we need to set up a hack date to create a Probot, Charles. CHARLES: Seriously, my mind is brewing. ROBERT: I guess it's not directly related to GraphQL but there's something that I've always wanted to build. For prior history to everybody [inaudible], then the podcast, Brian and I used to work at a company called IZEA and one of the things that we built and I worked on a lot was we would create a collect metrics on people's social accounts that they're connected and do that and graph it over time. This idea came from when I was building up that feature all the way back in 2013, I want to graph the change in GitHub stars. Is there an API available for me to see like weekly GitHub stars or is that something that I still have to manually store and track? BEX: There's definitely an API endpoint to get the amount of stars and I don't see why you couldn't just do that on weekly basis and compare but I don't think there's any track that change API. ROBERT: Gotcha, like a history of it. I could do this by just stealing and looking at what the weekly digest Probot is doing because there is a change in stars section in there. I was just curious if there was now an API that was available. BRIAN: Yeah, that's more unlikely. I'm going to say no without looking at all the reference documentation. I think as far as that database, it's something you'd probably have to collect on your own but it's also a good candidate for a GitHub app, where you build a service that you can actually track stars once you've installed it and then if you want to monetize it, you can actually pay for private repo or whatever stuff like that, if you wanted to. But it sounds like a great opportunity to see this in the GitHub/Probot listings. BEX: I actually just look this app really quick in our docs because I was curious but apparently, you can receive the star creation timestamps. That could be doable through timestamp usage. ROBERT: Oh, and then I just kind of loop through back and build your graph in there. BEX: Yeah. ROBERT: Interesting. All right. Well, [inaudible] I was going to do today. BEX: Yeah. But I think it's exciting to bot the weekly digest and then what you could extract from that into stargazing is that Probot scheduler, which is essentially this all Probot extension we made that triggers a Webhook on a scheduled time period because right now, the way GitHub apps works are so centered around Webhooks. It can be difficult to find a way to trigger an action on something outside of a Webhook, like on a schedule basis. ROBERT: Yeah, that would be really helpful. I can definitely see how that would be a problem, if it's very, very central to reacting to Webhooks and events that happen on the system. BEX: Exactly. ROBERT: You're just hoping that somebody comes through and creates an event at a specific time. CHARLES: Can I ask you a question about, it's definitely on topic of extending GitHub but currently, just a question about, where the line is between what you can and cannot extend? You mentioned, for example in the rewrite of the WIP bot, being able to throw out a big button that says override this merge. Are there any plans to be able to actually extend the UI in novel ways? Everything there right now is happening with API calls, with I assume, UI elements that are related but the UI elements are static. If someone wants to put a novel piece of the UI, that button is going to require an extension of the GitHub UI by GitHub itself. Are there any plans to be able to, I know it's a dangerous waters, perhaps at a limited fashion at first but maybe more so, add different interactions and the actual application. BEX: I think this is actually the most exciting future of GitHub as a platform. In the past, GitHub APIs have only specifically supporting things that you can do through the command line or you can do through GitHub's UI itself. The Checks API introduced the very first non-integration specific UI element essentially and the merge button that I was referring to in WIP is exactly that. It's essentially this button that you can change the text of it to be whatever you want and you can listen on that action and then you can do as an integration or an app, anything that you want based on that. I think that's the most exciting direction for GitHub. Because if you look at Slack, Slack is a platform that has sort of really impressive integrations in that response. Your apps on Slack can really do all of these things, use custom UI elements, so I think the most exciting features for GitHub as a platform is all of this customization and giving the power to the apps. ROBERT: Yeah, that sounds an awesome way to be able to extend GitHub without having to try and throw the feature on to GitHub developers. BEX: Exactly. I feel that a lot of the struggle right now is that there aren't these nice ways of communicating via apps because I feel lot of the apps and bots end up just commenting on issues and pull requests and taking up a ton of screen real estate as a result and I just think that that's not the way that bot should ideally interact with the GitHub platform. They should have their own space to exist and that's the feature I'm most excited for. CHARLES: Yeah. I can think of having like progress bars for CI checks and your various appointments. It's too exciting. I'm glad. That's definitely the response I was hoping to hear. BEX: Yeah. We're excited for it too. ROBERT: Basically, you all have a massive community of a bunch of developers that would want to do this and are willing to get their hands dirty on it. Enabling that community is probably the root of all Probot is about. That's super awesome. BEX: Yup. CHARLES: That's a good place to end, because gosh, it's going to be so exciting to have the millions of developers on the planet, just like surgeon to the APIs that you're developing. BRIAN: One thing to add to that too, about the whole million developers, there's a number that's been thrown out from Stack Overflow and also, some other people who are saying like there's 50 million developers, there's 24 million developers. As far as GitHub, our public user number is 28 million, the cool thing about Probot and GitHub apps is that there's a good chance that all those people that are using GitHub today are not actually developers. They're like PMs or designers and what's really cool about this, like having interactions with that kind of platform in this way is that you can now enable all the non-developers to be able to interact with your GitHub repos and start bringing more designers and PMs onto to the GitHub platform to interact with the developers. ROBERT: That is an interesting point. That is awesome and something that I'm always looking for is a different ways to collaborate with non-developers on my team because... I don't know, developers tend to think everything is always centered around code but it's not. The shifting at work that are awesome, needs a lot of collaboration from non-devs and non-dev skills. That would be really interesting to see. I'm excited for that to play out. BRIAN: Yeah. There's a blog post that was published a month ago, I think about where the design team, design system teams rather, built the integration to Figma to update their icons effectively. I just posted that in the chat to look into but they also built this as a Probot app as well. ROBERT: That is awesome. BEX: Yeah, that one is super exciting. You would have the app comment, the diff between what the old icon versus what the new icon look like and it's just such a beautiful design change to be able to see that shift. ROBERT: Man, I'm happy that this is happening. The future seems super bright. Where can we direct people to get resources to contribute, to get involved and start really going at this? BEX: Basically, Probot.GitHub.io has all the Probot stuff, /app has all the listings for apps you can install today, /docs is where the docs are, if you want to get started and hopefully from there, we link up to the necessary things that you need to do. BRIAN: Also, what I mentioned too via Probot Slack channel, there's a Slack channel as well and they do a weekly call. I think, it's weekly or bi-weekly call to actually chat with the Probot community. If you have questions, you can actually bring your questions to the team. BEX: Yeah, we call it 'Office Hours' and it's once a week and it's under our community page, where we also have a link to our Slack. We have a link to another podcast we run and basically, how to get involved in the Probot community. ROBERT: Those are really helpful resources. I do remember seeing that Office Hours. It's on Thursdays, right? BEX: Yes. ROBERT: I was going to drop in for one and then, I actually forgot. Actually, it might be going on as we talk right now in this podcast. BEX: It starts in half an hour, I think. ROBERT: That's awesome. Cool. Well, thank you Brian and Bex for having a conversation about Probot. This is really awesome. Is there anything that you would like to plug for yourselves? How people can get in contact with you? BRIAN: Yeah, I am BdougieYO on Twitter. Everything you need to know about me is there and I am happy to say hello. I'm also helping with the GitHub developer program, which is sort of getting a soon-to-be announced rebranding. If you go to Develop.GitHub.com/Program and you want to have more conversation about the API and GitHub apps on the GitHub side, you can go there to sign up. BEX: And I am HiImBexo on Twitter. You can ping me in any Probot stuff. I'd be happy to look at any Probot code. I've been looking at it for a while now so I'm happy to do that. ROBERT: That's awesome. Thank you all for having a conversation with us. This was really fun. I'm so excited about everything you can do with Probot. This is a really fun project. I'm happy that this is happening and I will make a Probot in the future. CHARLES: I'm looking forward too. Robert has been excited for quite some time and he definitely talks a lot about it and now, I have some insight as to what -- ROBERT: It's happening, I'm telling you. Well. Thank you for being here and we are the Frontside. We build UI that you can stake your future on. We are specializing in JavaScript. We can build anything that you want throw at us. We do functional programming, React testing, Vue, anything in JavaScript, we specialize in. As always if you want to suggest anything for us to have on the podcast or talk about, you can reach out to us at Contact@Frontside.io and like I teased earlier in the podcast, next episode is going to be all about Microstates, the immutable and functional state container, composable model system that we've been building, it's controls as a brainchild for the past two years. That is next episode and I'm really excited about that. It's a really fun API and expressive to build models with. Thank you, Mandy for producing our podcast and we'll see you next episode.

Love open source? Looking to break into the tech industry? Oracle's Vaishali Thakkar joins us to talk about how you can leverage your open source involvement to find work in the tech industry. We'll look at programs like Rails Girls Summer of Code and Outreachy that could be able to pay you as you upskill intro the industry alongside Vaishali's own professional journey.

Eberhard Wolff talks with Ute Mayer about Rails Girls. Topics include how Rails Girls increase diversity in IT and thereby influence the live of the attendees. Rails Girls is a global movement and does workshops to introduce women to programming. Attendees can then join project groups to work on specific projects and apply for the Rails Girls Summer of Code to develop open source projects. The training material is free and open source - and includes information how to start a Rails Girls group. There are many way to support: Rails Girls is looking for coaches and sponsors.

Before becoming a developer, Laura had a number of job titles, including music blogger, DJ, and maid. But it was a Rails Girls workshop that brought her back to the world of web that she fell in love with many years ago. Now, as a manger at the Travis Foundation, she gets to help introduce other women to tech through the Rails Girls Summer of Code, one of the many initiatives she runs. She tells us more about what it’s like to be a scholar in the program, the power of doing meaningful work on open source projects, and how she reconnected with the web and became a developer. Show Links Digital Ocean (sponsor) MongoDB (sponsor) Heroku (sponsor) TwilioQuest (sponsor) Girl Develop It Your First PR Katrina Owen Sinatra Google Summer of Code Women Who Code Exercism.io Discourse Fund Club Travis CI Travis Foundation Codeland Conf Codeland 2019

Show Notes und Links Laura Gaetano auf Twitter: @alicetragedy Lauras Homepage Rails Girls Summer of Code RGSoC on Twitter RGSoC Accepted Projects 2016 Travis Foundation Rails Girls Rails Girls on Twitter Ruby Habits Meetup vienna.rb Meetup Codecademy Coursera Mail Address of Rails Girls Summer of Code summer-of-code@railsgirls.com

Interview with Josh Kalderimis from Travis CI. Josh is a co-founder and Chief Post-It Officer at Travis CI. Topics What is Continuous Integration, CI What is Travis CI Some history of the company travis-ci.org vs travis-ci.com and merging the two Enterprise and the importance of security Feature questions Travis vs Jenkins Travis notification through Slack Reporting history of Travis results Dealing with pytest results status other than pass/fail Capturing std out and stderr logging from tests Build artifacts Tox and Travis Using Selenium What does a Chief Post-It Officer do Differentiation between Travis and other CI options Using Slack to keep remote teams communicating well Travis team Funding open source projects Travis Foundation Rails Girls Summer of Code Open source grants Mustaches and beards Shite shirts New Zealand What does Team Periwinkle do Links Jeff Knupp's Open Sourcing a Python Project the Right Way (https://www.jeffknupp.com/blog/2013/08/16/open-sourcing-a-python-project-the-right-way/) Sven's blog post when Travis started (http://svenfuchs.com/2011/2/5/travis-a-distributed-build-server-tool-for-the-ruby-community) Sven's mustache and Josh's beard (https://travis-ci.com/about) Travis CI for open source (http://travis-ci.org) Travis CI for private repositories and enterprise (http://travis-ci.com) Slack (https://slack.com/) Travis Foundation (http://foundation.travis-ci.org/) Rails Girls Summer of Code (http://railsgirlssummerofcode.org/) Talk Python to Me Podcast (https://talkpython.fm/episodes/show/45/the-python-testing-column-now-a-thing)

01:49 - Erik Michaels-Ober Introduction Twitter GitHub Ruby Rogues Episode #127: Erik Michaels-Ober 02:07 - The Crystal Programming Language and Statically Typed Programming Languages Erik Michaels-Ober: An Introduction to Crystal @ PolyConf 15 06:54 - Type Inference Union Types Duck Typing Monkey Patching Sandi Metz Blog Post on the Wrong Abstraction 15:06 - Crystal vs Rust or Go 20:10 - Linting Rubocop 20:44 - Type Annotations and Perimeters Keyword Arguments 22:53 - The History of Crystal and its Development as a Language Crystal Docs Crystal GitHub Repo The Future of Crystal (Christmastime Blog Post) 24:41 - Annotation and Return Value 25:35 - Type Inferencing (Cont’d) 28:24 - Crystal REPL (ICR) 32:15 - Getting Involved with Crystal and the Development of the Language Crystal to_proc 40:08 - Threading and Concurrency 44:28 - Crystalshards Crystal Weekly 49:30 - Use Cases and Benchmarks Crystal Standard Library wc.cr 01:03:15 - Compile Errors     More on Crystal Erik Michaels-Ober: Crystal Programming Language @ RubyC 2015 Interview for RubyC-2015 with Erik Michaels-Ober Built-in formatting tool Issue Picks Easy Bash Prompt Generator (Jessica) Logitech Wireless Headset Dual H820e Double-Ear Stereo Business Headset (David) Ruby Rogues Episode #127: Erik Michaels-Ober (Erik) fish shell (Erik) Rails Girls Summer of Code (Erik) RescueTime (Avdi) The 7 Habits of Highly Effective People: Powerful Lessons in Personal Change by Stephen R. Covey (Avdi) Whiplash White IPA (Avdi)

01:49 - Erik Michaels-Ober Introduction Twitter GitHub Ruby Rogues Episode #127: Erik Michaels-Ober 02:07 - The Crystal Programming Language and Statically Typed Programming Languages Erik Michaels-Ober: An Introduction to Crystal @ PolyConf 15 06:54 - Type Inference Union Types Duck Typing Monkey Patching Sandi Metz Blog Post on the Wrong Abstraction 15:06 - Crystal vs Rust or Go 20:10 - Linting Rubocop 20:44 - Type Annotations and Perimeters Keyword Arguments 22:53 - The History of Crystal and its Development as a Language Crystal Docs Crystal GitHub Repo The Future of Crystal (Christmastime Blog Post) 24:41 - Annotation and Return Value 25:35 - Type Inferencing (Cont’d) 28:24 - Crystal REPL (ICR) 32:15 - Getting Involved with Crystal and the Development of the Language Crystal to_proc 40:08 - Threading and Concurrency 44:28 - Crystalshards Crystal Weekly 49:30 - Use Cases and Benchmarks Crystal Standard Library wc.cr 01:03:15 - Compile Errors     More on Crystal Erik Michaels-Ober: Crystal Programming Language @ RubyC 2015 Interview for RubyC-2015 with Erik Michaels-Ober Built-in formatting tool Issue Picks Easy Bash Prompt Generator (Jessica) Logitech Wireless Headset Dual H820e Double-Ear Stereo Business Headset (David) Ruby Rogues Episode #127: Erik Michaels-Ober (Erik) fish shell (Erik) Rails Girls Summer of Code (Erik) RescueTime (Avdi) The 7 Habits of Highly Effective People: Powerful Lessons in Personal Change by Stephen R. Covey (Avdi) Whiplash White IPA (Avdi)

01:49 - Erik Michaels-Ober Introduction Twitter GitHub Ruby Rogues Episode #127: Erik Michaels-Ober 02:07 - The Crystal Programming Language and Statically Typed Programming Languages Erik Michaels-Ober: An Introduction to Crystal @ PolyConf 15 06:54 - Type Inference Union Types Duck Typing Monkey Patching Sandi Metz Blog Post on the Wrong Abstraction 15:06 - Crystal vs Rust or Go 20:10 - Linting Rubocop 20:44 - Type Annotations and Perimeters Keyword Arguments 22:53 - The History of Crystal and its Development as a Language Crystal Docs Crystal GitHub Repo The Future of Crystal (Christmastime Blog Post) 24:41 - Annotation and Return Value 25:35 - Type Inferencing (Cont’d) 28:24 - Crystal REPL (ICR) 32:15 - Getting Involved with Crystal and the Development of the Language Crystal to_proc 40:08 - Threading and Concurrency 44:28 - Crystalshards Crystal Weekly 49:30 - Use Cases and Benchmarks Crystal Standard Library wc.cr 01:03:15 - Compile Errors     More on Crystal Erik Michaels-Ober: Crystal Programming Language @ RubyC 2015 Interview for RubyC-2015 with Erik Michaels-Ober Built-in formatting tool Issue Picks Easy Bash Prompt Generator (Jessica) Logitech Wireless Headset Dual H820e Double-Ear Stereo Business Headset (David) Ruby Rogues Episode #127: Erik Michaels-Ober (Erik) fish shell (Erik) Rails Girls Summer of Code (Erik) RescueTime (Avdi) The 7 Habits of Highly Effective People: Powerful Lessons in Personal Change by Stephen R. Covey (Avdi) Whiplash White IPA (Avdi)

Adam and Jerod talk to Anika Lindtner and Floor Drees about Rails Girls Summer of Code, Travis Foundation, fundraising, supporting open source through grants, and ways the community is showing their support of diversity in tech.

Adam and Jerod talk to Anika Lindtner and Floor Drees about Rails Girls Summer of Code, Travis Foundation, fundraising, supporting open source through grants, and ways the community is showing their support of diversity in tech.

Diesmal sprechen wir über sieben Möglichkeiten um mit einem Produkt Geld zu verdienen.  Show Notes RankSeller – Ein Marktplatz, um mit Links Geld zu machen Crosswind difficulties Rails Girls Summer of Code The post Folge 7: Wie man mit einem Produkt Geld verdienen kann appeared first on Nebenberuf Startup.

Scotty and John chat talk the WWDC ticket lottery, the Beautiful Pixels review of Findery, Rails Girls Summer of Code and Johns first peep at Android development.