• Oct 2, 2019

  • Played with the new metrics agent on the droplet. It’s properly reporting data now.
  • Created an email alert for mem > 90% for 5 min.
  • 
  • I’ll grab this again over about a week, to see mem usage increase in O(days), as well as sunday action.
  • CPU usage, disk i/o, process load – these are under control always, even on sundays. They only rail during a deployment..
  • Ducati hit 6000 miles today.
  • SF has a ton of food transportation startups.
  • uWSGI needs to re-enable the GIL with –enabled-threads in order to work properly with APScheduler.
  • Apscheduler doesn’t expose if a job is running. Absolutely ridiculous.
  • Chiro
  • Jinja blocks {% block %} cannot be conditional, you must put the {% if %} within them, not around them.
  • Started the brine for pastrami beef ribs. Basically just make a usual rub, but with about a tablespoon of pink curing salt. Bring half gallon of water to boil with the rub mixed in, the add the other half gallon of water to cool and then submerge the short ribs for a week.
  • Supercontest.
  • Added ADMIN_EMAILS to supercontest.util.email. Made each schedule notify me of start/stop as appropriate. Confirmed the following:
  • Email reminder runs once, and emails me the summary as admin.
  • Line fetcher prints every minute.
  • Live scoring verifications, in order:
  • Comment out all of commit_scores until the live definition, then modify as necessary.
  • Add to the bottom of get_app() before the scheduler.start() call:
  • import datetime
  • from supercontest.schedule import add_live_scoring_jobs
  • datetimes = [datetime.datetime.utcnow() + datetime.timedelta(minutes=1)]
  • add_live_scoring_jobs(datetimes)
  • Visit the /scheduler endpoint during all of these tests.
  • Tests:
  • Scores are fetched every minute if a line’s datetime is reached.
  • Shim the datetime input to add_live_scoring_jobs() with one datetime and live = True.
  • Score fetching only runs one job when multiple games are active.
  • Shim the datetime input to add_live_scoring_jobs() with 2 datetimes at the same time. Keep the live status.
  • Score fetching is stopped when all statuses are F/FO.
  • Set live = False. Make sure it emails you.
  • Future schedule jobs remain after removal of the current.
  • Add a third datetime before the other two. Leave live = False. When it is removed, make sure the next two are still scheduled in the future.
  • Then undo the first two actions.
  • New lines end the fetch job, and an email is sent.
  • I’ll have to verify that the score fetching works fully, with real data, tomorrow.
  • Fixed the cyclic imports by lazy-loading the wrapped functions inside the job targets.
  • Adding a new navbar for admin (dashboard and scheduler). These do not participate in the nav_active regime.
  • Updated banner, usual wednesday deploy.
  • Deployment takes about 4 minutes.
  • Was getting a weird KeyError: 5 in the limbo period between 5pm when the db week turnover and the new line commit happens. Could not reproduce in the dev env. I’ll check next week again. Could have been some compound issue with the broken line fetcher (hopefully…bc that’s fixed).
  • Added protection that if the lines are already in the db for the current week, remove the job and stop (don’t commit scores, don’t run another fetch again, don’t email, etc).
  • Split up the templates into a navs/ folder. SO much better now.
  • Consolidated all the menus into one smart huge navbar. The template hierarchy is a lot cleaner too. All of the nav dropdowns are sequential, and then the final view extends them + fills out the main_content block.
  • Every view has league now. All of the conditional if statements to build url_for() calls are much simply now. It’s just one branch at max, checking if week is needed.
  • Played with the responsive capabilities of navbars: collapse at certain breakpoints, splitting into different submenus, etc.
  • Remember that to delete a row with fk constraints, you must delete those rows that reference them (for example, you can’t delete line rows until the score rows that reference them are deleted as well).
  • The jinja block you’re filling doesn’t have to be in the direct parent you’re extending. It can be way up the lineage.
  • The href=”#” on an <a> tag tells the browser to treat it like a real link. Without that, it won’t show the click cursor (the hand) – instead it will show a regular pointer or typing cursor.
  • FDT needs a body tag, so add it if you want the toolbar for even basic endpoints that return pure html or raw strings.