Hello and welcome. We're going to use this lesson to talk about quality of life for developers. Early on in my career, I didn't invest a lot of time into configuring my development environment. Don't get me wrong, I installed the tools that I prefer to use and I'd even select a canned theme for whichever code editor I was using, I just didn't go much beyond that because I didn't see the point.

Over time, I began to find more value in configuring the software that I most often use. With the amount of time that I was spending on the command line, I was losing little bits of time by not having at-a-glance access to certain information. I was also losing time by using default components that really didn't resonate with me.

Eventually, I began to start configuring my development environments to match the project. Everyone has their own way of thinking and learning. No one piece of software is really going to work well for everyone, so customizations are one way that we can change tools to fit our own mental models. They can also bring along a visual aesthetic that makes a given piece of software a better user experience.

So we're going to go theme shopping. Now technically, I've already selected the theme I'm going to use for this project, however, we're gonna check out a few anyway. I'm using Bash inside of the development VM, so I'm gonna hit up the Git repo for oh my bash.

On the Themes page, we can see some of the screenshots of the different themes. One of the first themes listed is rather nice. It builds on top of the Powerline fonts to make these nice stylized prompts. Scrolling through, you can see that there are a lot of themes. The theme I chose for this project is called Cupcake. It's a minimal, multi-line prompt that uses emojis.

As I scroll through, if any of these jump out at you, then it may be worth investing some time into finding your next theme, even if it's just a starting point where you modify from. Different shells will have their own way of implementing themes.

For z shell users, oh my z shell, and it has a lot of themes these are kind of similar to the ones we just saw for Bash. Powershell users can get in on the theming as well, with different resources such as this one, offering pre-configured themes. I chose to use Cupcake theme as my starting place.

I installed oh my bash by running the provided install script, and this overwrote my existing bashrc file, though, it did back it up first. In order to select the theme, I set the OSH_THEME variable inside the bashrc file, to cupcake. I ended up making a couple of small changes to the theme. I set the Virtual Environment icon to be a snake emoji, and I made a couple other substitutions here for the emojis.

In the end, this is what it looked like. In addition to changing the theme of the shell, I also wanted to improve the unit test experience for this project. To do that, I installed two Pytest plugins. The first is called pytest-cov and it adds code coverage info to our testing output. Having easy access to code coverage helps us to identify areas of the application that aren't exercised at all.

The second plugin is called Pytest-sugar and it adds better visuals to the testing output. Here's a look at the results of running the unit tests. Notice these nice progress bars, we get these nice green checks for passing tests, we get these blue s's for skipped tests, and we get this nice coverage summary. The Missed section here even tells us which lines of code aren't exercised at all.

These are all just small changes that can make development easier. Aesthetics aside, there are some changes that are about usability. When I was a .NET developer, I spent most of my development time in Visual Studio. Visual Studio is an integrated development environment. It has everything built into the UI, and it also allows for plugins.

Setting breakpoints and debugging was really easy, you'd click on the line you want to break on and start the debugger. As I moved into other languages, such as Ruby and Python, I started to use more minimal code editors and I found debugging to be much more effort than it had been with Visual Studio.

So I ended up relying on print statements quite often for my debugging. Which, if I'm being honest, I still use on occasion. However, that changed for me when I started using IPython because I found it to be more user friendly. Python 3.7 added a new function called breakpoint. When called, breakpoint determines which function to run by checking an environment variable named PYTHONBREAKPOINT. This means that we can easily swap out the debugger.

For this project, I'm using ipdb as the default debugger. The ipdb library is basically a drop in replacement for pdb, only it uses IPython. IPython shells are intended to be more user friendly. They can offer syntax highlighting, tab completion, magic commands, and more.

By setting the Python breakpoint variable to ipdb's set_trace, we can use ipdb whenever we call the breakpoint function. This means when we enter an interactive session while debugging, we can use an IPython shell. However, out of the box, it's configured to use the way I want it, so I'm making a few changes.

I'm using a .pdbrc file to create a debugger command that will start up an interactive shell configured the way I want. This file resides in your Home directory and is read when debugging. This is the contents of the .pdbrc file that I'm using in this project. It enables syntax highlighting inside of the IPython shell, and whenever I'm working on new APIs or data sets, I like to be able to visualize things and I find that a key part of that visualization for me is syntax highlighting and output formatting so this is going to help with that.

Taking the time to configure your environment for the project or projects you're working on can help to improve your development-quality-of-life. Better visuals and better tools can help streamline your workflow. However, better is a subjective term so, it may take some effort for you to find what works best for you.

All right, that's going to wrap up this lesson. Thank you so very much for watching, and I will see you in the next lesson.

Lectures

Course Introduction - What Is It That We're Building? - Exploring the Data Access Layer - The Web Server Gateway Interface - Exploring the Web Application Layer - Exploring the Front End Code - Running the Web App - Summary / Next Steps