| ###### base widgets | |
| import ipywidgets as widgets | |
| widgets.IntSlider( | |
| value=7, | |
| min=0, | |
| max=10, | |
| step=1, | |
| description='Test:', | |
| disabled=False, |
This file is for notes for my podcast episode, created as part of Florida Polytechnic University's FA 2022_MAN5245.01.
Working in open source is a very different world than a typical managerial setting...
managment? contributors? decision makers? users?
| from vetiver import VetiverModel | |
| import vetiver | |
| import pins | |
| b = pins.board_rsconnect(server_url='https://colorado.rstudio.com/rsc', allow_pickle_read=True) | |
| v = VetiverModel.from_pin(b, 'isabel.zimmerman/iz-bike', version = '58519') | |
| vetiver_api = vetiver.VetiverAPI(v) | |
| api = vetiver_api.app |
Notes from The ML Test Score: A Rubric for ML Production Readiness and Technical Debt Reduction By: Eric Breck, Shanqing Cai, Eric Nielsen, Michael Salib, D. Sculley
| Test | Example |
|---|
GITHUB ACTIONS ARE FOR EVERYONE* 😰😰😰😰😰😰 *who is making a project that requires testing and documentation.
GitHub has been in my nearly daily use for a few years now. I’d spent months trying to conquer pushing, pulling, rebasing, opening issues, making templates, using keys, and no longer started sweating when I had to solve merge conflicts. But there was a big missing piece in my GitHub education: actions. GitHub actions was a tab I had never ventured to click on, mostly because I didn’t know what it did besides “CI,” which seemed like overkill for my simple projects.
tldr; GitHub actions are workflows that run every time you interact with your repo. You can specify what the workflow is–generally, it is running tests, building documentation, and checking code coverage. You can also specify what the interaction is–generally, the workflow runs on every push or pull request.
Best uses for GHA:
You will need two different repos, a sending repo and receiving repo. In my case, the sending repo generates a cookiecutter template for a Python package, and then the receiving repo is the output package. You don't have to be familiar with cookiecutter templates to understand this gist, but they're worth a quick click if organization brings you joy.
Before running your chain reaction of actions, a few pieces need to be set up. The receiving repo cannot be empty, so I just initialized it with an empty README.md. The next part is probably the most difficult if you're unfamiliar, which is generating an SSH key, click here for instructions. Once you've gone into the terminal and generated
| library(shiny) | |
| library(tidyverse) | |
| library(dbplyr) | |
| library(lubridate) | |
| library(RPostgreSQL) | |
| library(prophet) | |
| library(config) | |
| library(jsonlite) | |
| library(V8) | |
| library(bslib) |
A1: Yes! (Visual storyteller, Data analyst)
A2: Love it for someone else (Data scientist or data engineer)
A3: Nope (Not data)
A1: Identify a methodology, test it, execute, and test to make sure it worked as intended (data scientist or data engineer)
| #clean tweets | |
| clean_tweets <- function(x) { | |
| x %>% | |
| str_remove_all(" ?(f|ht)(tp)(s?)(://)(.*)[.|/](.*)") %>% #remove URLs | |
| str_replace_all("&", "and") %>% #change & to and | |
| str_remove_all("@[[:graph:]]+") %>% #remove @ | |
| str_remove_all("[[:punct:]]") %>% #remove punctuation | |
| str_replace_all("\\\n", " ") %>% #remove \n | |
| str_replace_all("\\\r", " ") %>% #remove \r | |
| str_replace_all("\\\u0091", "") %>% #remove \u0091 |