Yeah, I’m dragging my butt through the program. A warning signal is going off in my head, this is not how you create a new habit. But also, you should not kill yourself to force a new habit. You need it to be easy, otherwise if it becomes hard then you hit resistance, and resistance is a brutal killer of new habits. So if you need to take an extra day to continue on your habit that is okay, but be sure to do the minimum you can everyday. Lets look at what I’ve been working on over the last weekend.

# Day 3 – Leap Year

Write a program that works out whether if a given year is a leap year. A normal year has 365 days, leap years have 366, with an extra day in February.

Dr Angela Yu. 100 Days of Code: The Complete Python Pro Bootcamp for 2022

I spent extra time to document the process of figuring this out. When the code gets topsy turvy like this I like to write it out in english, it helps tease out the flaws in my logic. I made Several bugs writing this, like not setting the flag false if it is not divisible by 4. I removed an extra if statement and moved the assumption statement to be prominent at the top.

The last line 25 is a bit of trick, rather than use if then else to print the statement I used the position in the array to print out the right statement. There are two results. False = 0 and True = 1. So I used the positions 0 and 1 in the Array to store the values. When I print the result I use the True/False variable to select which statement to use.

# Day 3 – Pizza Shop

Another if else test. I didn’t use elif. I could have used elif for the pizza size, but didn’t feel it needed it to make it better.
What I like about code like this is I can simulate the process. And holy shit this is an epiphany! I should use this to document my processes at work! Let’s stay on task though, I’ll write about that next. Back to why I like this, the person who is taking an order needs to understand that additional pepperoni is a different charge for the size of pizza. So that logic needs to be trained to the new employee. But something like this is never mentioned during training. It’s always added when someone realizes the total is not right, then they go back and tell the new employee about the different rates of pepperoni charges.

I feel like coding is a way to document this better than with a flow chart. I find flow charts are cumbersome to illustrate.

``````# 🚨 Don't change the code below 👇
print("Welcome to Python Pizza Deliveries!")
size = input("What size pizza do you want? S, M, or L ")
add_pepperoni = input("Do you want pepperoni? Y or N ")
extra_cheese = input("Do you want extra cheese? Y or N ")
# 🚨 Don't change the code above 👆

#Write your code below this line 👇
price_small_pizza    = 15
price_medium_pizza   = 20
price_large_pizza    = 25

total_price = 0
if size == 'S' or size == 's' :
total_price += price_small_pizza
if size == 'M' :
total_price += price_medium_pizza
if size == 'L' :
total_price += price_large_pizza
if extra_cheese == 'Y' :

## Code as documentation brain spill

I don’t like documentation to explain processes. The usual process is that I need to write documentation, then I share it around. People usually look it over but don’t take time to read it and process it. I end up having to verbally explain nuances in a meeting and people look at me weird, then agree it’s fine, and the documentation is never brought up again, until someone needs it. Then we may update it. The greater problem with this is it is not a suitable documentation method. If I wrote a simple javascript program in an HTML page then people could simulate the process.
I’m thinking the ticketing process for new laptops. I could create a text based adventure game for creating a new laptop request, and simulate it through to the end. I could write a simulator for the whole process. Cool!

So I tried to write a simple demo, but there is overhead of interacting with the end user. So I found a terminal emulator library here:
https://terminal.jcubic.pl/#demo
I’ll take a look at this to see if I can use it…

# Day 3 Love Calculator

Another day IRL has passed. Meanwhile I’m still on day three of the python programming course. Aside from not feeling well, I enjoy taking the time to play with the code somewhat. For this lab I mixed up what I was supposed to be tallying. So I needed to add in some debug messages.

``````print("Welcome to the Love Calculator!")
name1 = input("What is your name? \n")
name2 = input("What is their name? \n")

lower_names = [name1.lower(), name2.lower()]
test_words = ["true","love"]
match_res = []
total_score = 0
##### Test how many times each letter in the test word matches in a name
for aword in test_words:                           # Cycle through the test words
letter_hits = 0                                # Reset the word hit counter
for aname in lower_names:                      # Cycle through the names
for wletter in aword:                      # Cycle through the letters of word
countres = aname.count(wletter)        # Count instances of letter
letter_hits += countres                # Add it to tally
#print("{} finds {} of {}".format(aname,countres,wletter))  # Debug Print
match_res.append(letter_hits)                  # Save count of the hits in names
#print("{} tested with word {} result is {}".format(aname,aword,letter_hits))  # debug

#funky Love test rule combine the numbers as strings to makeup new number
match_score = int( str(match_res[0]) + str(match_res[1]) )

if match_score < 10 or match_score > 90:
print("Your score is {}, you go together like coke and mentos.".format(match_score))
elif match_score < 50 and match_score > 40:
print("Your score is {}, you are alright together.".format(match_score))
else:
``````Welcome to the Love Calculator!