4/21 UI and Jekyll
3/14 ML | Titanic Data
Everything above predicted survival is making the model Everything below predicted survival is us giving inputs (e.g. asking chatgpt) and getting a response from the model
3/13 PPR Review
No comments Correct convention (e.g. camelcase vs pascalcase) Use chatgpt for explainations be clear with were and what the variables are and where it’s being used
3/12
Data Frames | Pandas | Intro 1
Data Frames - like a table, spreasheet, etc DF = smth, DF = data frame
1/28
AWS Deployment
Port: 85 (table number, 05) - for your team
1/14
Requestion API Responee
Backend handles API, responses and requests by frontend CRUD:
- Create: Adds new data to a database
- Read: Retrieves data from a database
- Update: Changes existing data in a database
- Delete: Removes data from a database
Restful apis used 204 for no content usually
HTML 5 TABLE
HTML 5 FORM
1/8
SQL Alchemy (not SQL Connect - won’t be learning object oriented programming, will have collaboration difficulty.) app = Flask(name) <- not needed
code is put in classes to keep it away from the other code and encapsulate it.
table inside database, like a supercharged spreadsheet
user_management.db
the class in user.py is a template, and this ‘ def init(self, name, uid, password=”123qwerty”, dob=datetime.today()):
self._name = name # variables with self prefix become part of the object,
self._uid = uid
self.set_password(password)
if isinstance(dob, str): # not a date type
dob = date=datetime.today()
self._dob = dob’ makes an instance
init method allows
12/10
Little Server / Big Server. I will go over these in class today. The struggle is great for many transitioning from my Jupyter Notebook to making an API in the big system. I suggest the following progressive steps … Make a Little Server (app.py). Place it at the root of the project, same level as main.py. Runt the app.py as its own server and port. This should be a direct copy minus %%python magic command. Do a live share make several endpoints and functions named after each group member (ie /api/john). I suggest doing Live Share session, thus avoiding merge conflicts. Get this running and then test from Browser and Jupyter notebooks. Be sure to make a review ticket for this item and remember your process. Big Server step. Try to make an API in the big system, using the big system style of code for API’s. This will require that you start a new file in the api directory of the project. The file will use “blueprint” style of coding and needs to be registered in main.py to become visible in the big project. Below is a template you could Live Share that uses a different technique for making a restful API. Return dictionary for each person, return a list of persons. Big Server with database step. This would be the next step. This is pretty much implemented for users of the system using user.py. FYI, these changes can stay in you repository and will have no impact on other functionality. Be sure to document process as you go, as this is as much about the process as the code. In this activity, you should be ultimately thinking of how to build the following features: User Profile, Admins of System, Users of System, About page for Creators, Blog page for supporting users and contacting creators, etc
- blueprints a file organization technique
from flask import Blueprint
from flask_restful import Api, Resource # used for REST API building
student_api = Blueprint('student_api', __name__,
url_prefix='/api')
# API docs https://flask-restful.readthedocs.io/en/latest/
api = Api(student_api)
class StudentAPI:
class _John(Resource):
def get(self):
# implement the get method
pass
class _Jeff(Resource):
def get(self):
# implement the get method
pass
# building RESTapi endpoint
api.add_resource(_John, '/student/john')
api.add_resource(_Jeff, '/student/jeff')