I just finished day 11 of 100 days of Web with Python and am pretty pleased with how it went. The past 2 days were following along as the instructor setup an API using API Star. While overall I was able to follow along with the tutorial, there were a couple of instances where Bob (the instructor) jumped to the next step with little or no explanation and I was playing catch up. In particular, since I had never used “breakpoint()” before, when he ran the application and there was suddenly a “pdb” prompt I was very confused. I got it figured out, but I probably re-watched that part of the video 10 times trying to figure out where the “pdb” was coming from.

breakpoint() is pretty slick!

That being said, I think that “breakpoint()” is one of my new favorite functions. Apparently it was added in Python 3.7, and implements PEP553. Basically it gives you a prompt at that point in your program so you can check variable states and test functions, etc. For more information about the breakpoint() function, see this quick tutorial on Hackernoon. I can definitely see using this in class next year. Unfortunately, Kubuntu 18.04 is still on Python 3.6. I guess that means I’ll be upgrading to 19.04 in the Fall. That’s ok, I was already thinking about switching the class to Xubuntu.

CRUD Operations

Back to APIs…I actually had my 2nd year classes do some work with open-notify.org, an API for checking the whereabouts of the International Space Station, so it’s pretty neat to see how to develop the API itself.

This was my first experience with CRUD operations since my databases class in college. CRUD is an acronym that stands for Create, Read, Update, and Delete. These are the primary operations you do on elements in a database. For this particular project, we used a dictionary instead of a database, but I can see where (probably) with a few minor changes to the code, we could be using an actual database back end.

Where’s the data?

An important part of building the API is getting the data. But finding data for testing things can be difficult. I mean, it’s EVERYWHERE, but in my experience it’s often behind a pay-wall or isn’t in a very usable format for testing things. That is where Mockaroo comes in. I hadn’t seen this tool before. Basically, it lets you get up to 1000 randomly generated rows of data in JSON, csv, xls, or SQL. That’s really cool. I think we may use this next year for some practice processing csv files.

Pytest

Another major part of the past two days was using Pytest for testing the functions. In class, I have my students use the doctest module, so I don’t have any experience with Pytest. I’m looking forward to diving in tomorrow to see what is involved and may consider using it instead next year. A big advantage to doctests is they can be inserted in as documentation in the code itself. The downside to this is it (in opinion) potentially makes the program much more difficult to read. It might be nice to just have a separate .py file with a bunch of tests that I can put in the starter repo. I know you can do the same thing with doctests basically, so I’ll have to weigh the advantages and disadvantages of each a bit more.

Days 6-7 of the 100 Days of Web with Python involve recreating Google’s search page from 1998 (the logo belongs to Google, of course). It was a pretty fun exercise but didn’t take me very long. I did cheat a little (I looked at the HTML file on Google’s page in 1998 to see how they did their tables). Once I stopped thinking of a table as an Excel spreadsheet-like thing, it really made recreating the page much easier. Since it didn’t take me very long to get the basic page recreated, I decided to go ahead and work ahead. Here is my Github repo for this project.

Day 8 asks you to create a simple form for someone to register on Google (or something like that) and not worrying about style too much. Here is my form:

As you can see, it’s pretty basic. I think it’s really nifty that the input field can auto validate different types, including e-mail and date. Of course the form looks kind of ugly right now. I don’t particularly like how the date input is clearly a different size from the others. So after a quick Google search, I came across the style=”width:” and set each of the input boxes to the same width:

Still not perfect, but better. That’s one of the things I love about this stuff. If I don’t know how to do something, I can just look it up and generally find an acceptable way. What I don’t like is always wondering if the way I did it is the ideal way or the industry standard. That second one in particular really matters to me as a teacher. I do my best to teach my students in industry standard ways, or at least what I think they are. Sometimes a solution on Stack Exchange may just be a hack, and not really the right way of doing something.

This dilemma of industry standard practices has to be one of my constant struggles. Since I have 0 experience in industry, I’m never 100% sure what I’m teaching is a best practice. I base most of what I teach on blogs, online tutorials, and books, so I would like to think the people who write these things know how programs are written in the industry, but maybe they don’t. I mean, they have to at least know more about it than me right? But then again, here I am blogging and some new person might see my code and think I know what I’m doing. I wonder if everyone feels this way. I’ve heard it called “imposter syndrome”. Maybe I’ll do another post about that another time.

Just finished day 5 of 100 Days of Web with Python. I’ve always wanted to learn HTML, or at least enough to make decent web pages. Oddly enough, by working through this one lesson, I learned more than I ever have. Michael Kennedy does such a great job of explaining things, and I’m really enjoying working through the exercises with him. Here is my Github repo for today’s stuff. It’s basically the same as the one on their site. Days 6-8 involve remaking Google’s page, then making a submission form page. I’ll put them in that repo as I work through them as well.

I decided to make a list of a few of the things I’ve learned so far:

VS Code Tricks:

• ctrl-shift-alt-numpad down = duplicate current line (or selection)
• VSCode has a ton of autocomplete stuff for style=
• VSCode will auto-complete images if they are there…very cool.

HTML Stuff:

• I understand <div> tags now! Wow, how simple. I see <div> everywhere on web pages and now I understand why.
• Use <strong> for bold.
• Use <input type=password> for password field
• There are quite a few input “types” and VS Code will auto-complete
• Add the `required` keyword to an input if it is required

After completing this lesson, I began wondering what is being taught in the high school web design course. I need to go take a look at the curriculum. This is pretty simple to get going it seems like.

After 5 days, I’m extremely pleased with my purchase, and am very much looking forward to the next 95 days!