Programming By Stealth

In our previous installment of Programming By Stealth, Bart introduced us to Chezmoi, an open source tool to help us manage dot files, those hidden configuration files that get created on our Macs. Configuration files contain information about how we like our Macs configured, including where to access our ssh keys and our preferred command line editor and more. If we move between computers it would be nice to have the same configuration, or if we do a clean install it would be great to be able to have these dot files in place on our newly-formatted machines. He teased us last time though but just introducing us to Chezmoi and not letting us do much. In this installment he lets us take Chezmoi out for a spin. We edit an environment variable to set our preferred text editor, and then use Chezmoi to talk to Git to add and then commit those changes. Along with more changes and actions with Chezmoi, Bart works hard to cement the terminology of Chezmoi because without it, it's easy to not realize what Chezmoi i

As we've become nerdier while learning from Bart, we had started to add hidden configuration files to our Macs and PCs. On the Mac, these configuration files hidden by default by putting a dot in front of them, and hence they are called dot files. Maybe you've stored your ssh keys, or in our Git series you created a user-level gitconfig file, or perhaps you've installed VS Code or Sourcetree which also add hidden configuration files. In this installment of Programming By Stealth, Bart explains the problem to be solved of how we manage these configuration files if we use multiple computers or migrate to a new computer or do a nuke and pave. He lays the groundwork for why he loves the dot file manager called Chezmoi from chezmoi.io. The installment is a bit of a tease because after learning why we want to have a dot file management tool and why Bart favors Chezmoi for the job, he only lets us install it and run two commands before he says, "And next time we'll start to use Chezmoi."

A few weeks ago I told Bart off the air that when he was done with his mini-series within a series all about the version control system Git, I'd like a few minutes with him offline so he could explain how to ignore files in Git. I knew there was a way to do it but he hadn't covered it so I assumed it was just something quick he could explain to me. His reaction surprised me, he said, "D'oh!" because he realized that this is a _very_ important part of using Git and that he would definitely dedicate an installment to it. So this week Bart teaches us how to use `.gitignore` to tell Git _not_ to track changes to files and folders. He explains that there are files your computer or even your code editor may be creating that you don't want Git to track, and of course there all of the dummy test files we as humans create that would not be something we'd want to share with our co-workers or fellow open source contributors. I was nervous about using `git ignore` because I understood it relied on patterns, and I thought

As promised, Bart takes us through the final step in our GitHub journey - learning how to contribute to an open source project. He explains three open source scenarios: using someone's code exactly as-is, using their code with a few customizations of your own, and finally the most interesting scenario, customizing the code and contributing your customizations back to the project. When he gets to the final scenario, he gives us a way to practice these newly-acquired skills, and it's something he's wanted to do for a long time. He's created a gallery for all Programming By Stealth listeners to contribute their work they've done in the various challenges we've worked in Programming By Stealth. If you have your code from the challenges for Conway's Game of Life, the number guessing game, the currency converter, the currency grid, the world clock or the time sharing clock, we'd love to have you contribute to the PBS gallery to show off your work. Bart explains that the GitHub Pages he's created will allow us to f

In this installment of Programming By Stealth, Bart Busschots teaches us how to use a free service of GitHub called GitHub Pages. This service literally gives you free web hosting for the web apps we've learned to make in Programming By Stealth. Bart starts by explaining to us the difference between static and dynamic webpages, and web pages created by static site generators like Jekyll which generates GitHub Pages. It's trivially easy to create a GitHub Page from an open GitHub repo (literally three clicks in the interface) but it's really important to understand what you're doing when you take advantage of this service. We'll learn what you can do and what you can't do and what you could do if you choose to dig deeper into the woods on how to use Jekyll to generate GitHub Pages. I'm really excited to learn about GitHub Pages and how easy it is to host all of the web apps we've created in this series. You can find the shownotes at pbs.bartificer.net/...

In this week's installment of Programming By Stealth, Bart teaches us how to use GitHub as a public repository for our code, or for anything we write for that matter. He reviews whey he chose Github, and then we dig right in. He does explain the benefits of using SSH to access Github instead of HTTPS, and if you haven't set up SSH keys before or you're rusty on the topic, he includes links to our sibling show, Taming the Terminal where you can learn how to do it. We create a new repo from scratch in Github on the web with a README file and a license, and then we get to use a command line version of Github called `gh`. With `gh` we pull the repo down from Github, we edit the files, we commit them locally, and push them back up to Github all from the command line. We then flip the tables and from the command line create another repo directly on Github, create some files, set them up to track and push and pull again to prove it's working. It's surprisingly easy and simple. Bart teases us with the next episode

In previous installments of our Git miniseries within a series in Programming By Stealth, Bart taught us how to work in Git standalone on one computer, then how to work as one developer with multiple computers. In those installments he taught us the necessary commands and their importance in the Git scheme of things. In this installment he talks about how and where to work with a team in Git. We learn about the plethora of options from free to full enterprise-size Git-as-a-service, and why he'll be focusing on Github for the future. He explains how important it is to set up conventions for your team (before you start) for things like coding styles, development paradigm and more. There's no coding in this episode as it's more philosophical than other episodes. You can find Bart's fabulous shownotes over at pbs.bartificer.net/pbs115.

When Bart started this mini-series within a series on using Git for version control, he explained that our journey would be in three Phases. Phase 1 was the section where we learned about local repositories, and Phase two was dedicated to learning how to have multiple repositories just for ourselves. In this lesson, we finish up Phase 2 by learning how to push and pull changes from our imaginary desktop to our imaginary NAS to our imaginary laptop and back. I slowed down the class a few times with some confusion I had, but Bart always claims that my confusion often helps other people who might be hung up on the same thing. I enjoyed myself immensely, even when I was confused! We are about to enter Phase 3 where we will learn how to collaborate with others. We'll be doing this collaboration using Github, because it's pretty much the defacto home for most open source projects. When you're done listening to PBS #115 and studying the shownotes, you might want to get yourself a Github account so you can be ready

We continue on our journey to learn how to use Git to do version control as a single person, but this time with multiple devices. As Bart says during this episode, "Who is learning to program here who doesn't have multiple computers?" We've learned how to push our changes to a single separate repo, but we had to always say what branch we wanted to push to what branch on the origin. In this installment we learn how to tell Git to _track_ our branches so they stay in sync without us having to tell Git every time which branches to push where. We also learn how to make sure our annotated tags get pushed as well by setting a single repo or all Git repos on our computers to push our tags. Bart leaves us with a big tease at the end. We learn how to clone a repo in preparation for having two computers accessing the same code in Git with a primary source acting as the go between for them.

Last time on Programming By Stealth, Bart introduced the concept of remote repositories, also known as remotes. It was one of those episodes where we learned a lot but didn't get to apply what we learned. In this week's installment we get our hands digitally dirty as we create a _bare repository_ (a repo with no working tree), and declare it to be a backup of our local repo. We learn how to fetch and view remote branches and tags, how to push everything to the remote, and then after making some changes, push them to our remote backup. We're still in a bit of a sandbox as we do all this on one computer inside a couple of local folders, but the lessons exercise our new muscles to get ready for the big leagues. Bart's excellent tutorial show notes are as always available at pbs.bartificer.net/... [audio mp3="https://media.blubrry.com/nosillacast/traffic.libsyn.com/nosillacast/CCATP_2021_04_03.mp3"] mp3 download

In this next installment in our mini-series on learning Git, Bart Busschots gives us some foundational knowledge on how to work beyond being one person with one Git repository. He starts by reinforcing what he's explained before, that Git is a peer-to-peer technology, which is hard to wrap your head around if you're used to client-server relationships. He walks us through three scenarios to explain how every "actor" gets a repository and why. Then he explains the jargon of "local" vs "remotes". It's at this point that my head started to hurt, but Bart claims this is where I'm value-added to the podcast. I ask all the questions you might have, and I suspect many more than you have. Bart sticks with me and makes sure I fully understand. You can find Bart's tutorial show notes at: pbs.bartificer.com

In this installment of Programming By Stealth, Bart teaches us how Git can help us when we forget to switch to the correct branch before starting to make changes to our code. We're only human, and we will forget, and Git's `stash` command allows us to set our changes aside, switch to or even create and switch to the correct branch and then apply our changes. His explanations and repetition in the exercises really cement the knowledge. As a bonus tip, he teaches us how to make shell variables inside the Terminal which will help us with some of the repetitive typing in the future. Bart's tutorial shownotes are at pbs.bartificer.net/pbs111

In this installment of Programming By Stealth Bart teaches us how to deal with conflicts in branches of our code. He has been purposely only changing one thing at a time before now, but it's time to face the reality of when two branches change the same line in the same file. I've been terrified of this topic for a long time, but Bart shows us how easy it is to see exactly what the conflict is, how you can back out of merging if you make "a pig's breakfast" of it, and how to resolve your conflicts without fear. It's not nearly as terrifying as I thought it would be. You can find Bart's tutorial show notes at [pbs.bartificer.net/...](https://pbs.bartificer.net/pbs110) And if you learn a lot from Bart, please consider becoming a patron of his by going to [www.patreon.com/...](https://www.patreon.com/ltpod/posts)

We continue our mini-series within a series learning the version control system Git. We learn two methods to enhance our branching strategy. First, we'll walk through some basic principles on how to number our released versions of our code. From there we'll explore three types of changes that would cause a change in our release version: fixes, new features, and breaking changes. Each of these types of updates to the version of our code can be articulated with Semantic Versioning, also known as SerVer. This numbering convention informs users of our code on the meaning of each release. Finally, we marry these concepts by creating meaningful commit messages using another convention called Conventional Commits. Not only can a user of our code see at a glance what happened in a specific commit, documentation can be auto-formatted to explain the commits. There's not a lot of hands-on in this lesson but as a structured person, I really appreciate these conventions and why they're important. You can find Bart's tut

In this installment of Programming By Stealth, Bart Busschots continues on his series within a series explaining the version control system Git. We advance in our branching strategy by working several commits on our dev branch and then learn to use a merge commit to bring only the final commit into the main branch, leaving the half-working intermediate commits to exist only on the dev branch. This process illustrates the need to learn about tags, both light-weight and annotated. Once we understand how these tags work and their importance, we evolve our PBS branching strategy one step further. Bart's tutorial shownotes are available at pbs.bartificer.net/...

This week in our miniseries on learning the version control system Git, Bart dips our proverbial toe into branching. Branches allow us, as developers, to work on bugs or feature enhancements in a separate place from our stable code, and only merge the code back in when the bugs are squashed or the features are stable. We don't get much practice in this instalment, but rather Bart talks to us about the idea of having a strategy for when to branch and how to name your branches in order to prevent chaos. He gives us some simple and yet difficult to adhere to strategies and then takes us through more rigorous strategies that will actually be easier to follow. He emphasizes that he's not telling us which strategy to follow, but rather to have a strategy. We do a few small examples from the command line, but we get to open our Git GUI clients, like GitKraken and Sourcetree and see how the commands we're typing are graphically represented in the clients. It's a good illustration of what Bart has been promisin

As we continue to learn Git from the command line for version control, Bart teaches us some tricks to travel through time. First he shows us how to view more compact Git logs so we can just see a shortened hash and the first line of our commit message. Then he shows us how to pick out a single commit from the past and see what changed. Then he shows us how, with surgical precision, we can go back in time and get a single file or even just the changes from a specific commit and bring them forward in time. It sounds head bendy but I could immediately see the usefulness of going back in time and grabbing some code that was working well and bringing it forward. You can read Bart's tutorial shownotes at pbs.bartificer.net/...

Bart takes us on a time traveling adventure with Git. By using commands like `git diff` we can see changes over time, but we can actually see older versions of the code in a couple of ways. Using the `archive` command we learned out to pull just the files at a certain point in time (without the history) and the more terrifying `checkout` command that creates a "detached HEAD"! Bart even explains why that phrase was introduced and what it actually means. This was a fun lesson and a good foundation for what we'll learn next time, when we'll learn about stashing and branching to control the past and future.

In our next baby step in learning to use the version control system Git, Bart teaches us how to track changes. We start by doing a bit of housekeeping, especially for Mac users to set Git to always ignore those pesky .DS_Store files. We learn how to stage and then commit a simple change, then we stage and commit multiple changes and even learn to see the differences in our staged files from the database all from the command line. While we all think we're capable of making one structural change and then committing our changes, Bart knows that it isn't going to happen. But there's still a way to follow Helma's advice to "commit early and commit often". Bart teaches us how to divide the changes we inevitably make into separate commits with separate comments so we can figure out what we did later. I enjoyed this installment because I could tell it was laying a very important foundation of understanding. You can follow along with Bart's famous shownotes at pbs.bartificer.net/... allison@podfeet.com Support B

After some quick revision from the previous episode, Bart explains how Git commands work with their subcommands. We start by looking at how to configure Git and the differences between local, global and system-level settings. Then we create our very first repo with an exciting README file, and we commit the file to our repo. It's a fairly simple lesson while laying down a good foundation for all future work. You can find the shownotes for this installment at PBS 103 of X — Getting Started With Git allison@podfeet.com Tesla Affiliate Link podfeet.com/patreon podfeet.com/slack podfeet.com/facebook podfeet.com/paypal