• I care much less about the API utilization metrics that FMD provides. The most interesting is the API performance. Graph below. I wish they had multi-version api perf like they do for utilization. The results are mostly expected, but still an awesome feature. https://southbaysupercontest.com/dashboard/api_performance.
• 
• In checking back, you can see multi-version api perf for specific endpoints! Just not an overview of all routes for the application.
• South Park is back!
• FMD
• Verified that it CANNOT do patchfix version resolution. Only major and minor.
• A major version (3) was released yesterday, which appears to have broken the overview page. 3.0.3 was released a couple hours ago, looks like they've had a few bugfixes. Upgraded, and confirmed the overview is still broken.
• Maybe this line of questioning will help the lesser perspectives understand the ignorant racism in the NBA owner concession:
• Is it ok to compare someone to Saddam Hussein, when they have nothing in common with him except that they're Arab?
• Is it ok to compare someone to Hitler, when they have nothing in common with him except that they're German?
• Is it ok to compare someone to slaveowners, when they have nothing in common with them except that they're white?
• It it ok to compare someone to <anyone bad or good>, when they have nothing in common to do with it except that they share the same race?
• No. None of these comparisons are ok. They're offensive. Doesn't matter the historical subject/object, victim/aggressor, small/large, green/orange, old/young.
• All daemon threads will be killed when the last non-daemon thread dies. The non-daemons are the main ones. The daemon threads are subservient - they will not hold the main app.
• Supercontest.
• Got a few "AttributeError: 'AnonymousUserMixin' object has no attribute 'id'" errors in the production app, with an IP from singapore. This just means they tried to access a route and weren't logged in. The flask_user.current_user object is AnonymousUserMixin when the user is not logged in, so they can't do anything. The error was caught pre-route in the url_value_preprocessor.
• Right now, I have 94 compiled requirements (including testreqs) and 26 input requirements (not including testreqs).
• Remember that while 99% of requests make it to the app and you can check the standard uwsgi/flask logs (make logs-prod), there's a small chance that nginx catches something. just run `docker logs -f nginx-proxy` to check.
• Added text for harner's banner.
• Tons more work on the redesign of blueprints, routes, url_prefix, url_defaults, url_value_preprocessor.
• Used request.url_rule.endpoint and request.url_rule.argument to infer all of the  values (in g) that the current view would have access to. Then I conditioned the url_for() navlink builds in the templates based on those.
• It's all in a great place now. This was frustrating for a few days, but will be much easier to manage/change in the future without breaking things.
• Closed https://github.com/brianmahlstedt/supercontest/issues/102.
• Added apscheduler (advanced python scheduler) for the weekly email pick reminder.
• Not sure how, but two people submitted 10 picks into the db. Both were pairs of the same 5. I deleted them manually, but I'd like to know how this happened.
• Split up the utilities module into a separate util package, containing distinct modules for the specific type of functionality they provided. It was getting too big.
• Originally wrote the email reminder with apscheduler, but there's a specific flask-apscheduler that made it a little easier. Don't need to manage the debug app duplication, atexit, or any of that peripheral wrapping.
• Tested with my email only and a modified cron. Worked! The apscheduled job shows up in the regular flask logs too.
• Closed the weekly reminder ticket: https://github.com/brianmahlstedt/supercontest/issues/97.
• In debug mode, flask loads two instances of the application. If your app does something like schedule an external cron job, it will happen twice.
• Added Google Keep back to phone and to browser bookmark. I was missing the ability to immediately open something and jot a note down, especially while I was out and about, away from my laptop/blog.
• The `date` command in bash gives the local datetime with tzinfo.

• The amazon rewards card gives you 3% back at amazon. There's also a "reload" feature on amazon, where you put money in your account (for use at amazon) and it gives you 2%, plus $10 bonus sometimes. I tried reloading WITH my rewards card today. It won't let you.
• Electric toothbrush finally died, bought a new one. $50. Arrives tomorrow.
• Went to ortho in Van Nuys, got an MRI referral. Total round trip: 2.5 hours. 1.5hr driving, 1hr in waiting hour, 5 min visit with doctor.
• So far, the entire chain has been:
• spacex doctor -> spacex pt -> general doctor -> bloodwork -> general doctor -> xray -> general doctor -> ortho doctor
• 8 appointments, 8 visits, 0 conclusions. The referral system in medicine is terrible.
• There will be more. MRI -> ortho doctor -> whatever is next (hopefully not just PT).
• Idea: there should be a global medical database. You have to fill out the same new patient forms at every clinic you go to, and 99% of it is the same.
• Every office would have auth keys to a specific subset of the db: general information, surgical history, family history, ortho, respiratory, psychological, whatever. There would be a ton of different tables and only your office's specialty would be accessible by your office.
• This is just chrome holding all your passwords. They're collocated in a higher layer, the browser, and then every site uses only the ones it needs (and can only access the ones it needs).
• This would make the patient experience easier, would make referrals easier, would make everything easier.
• You could also do some machine learning once all the data was collocated. I guarantee there are correlations we don't see yet because all the variables are never observed together.
• Jinja can understand **kwargs, but the syntax is a little bit different than python: https://medium.com/python-pandemonium/using-kwargs-in-flask-jinja-465692b37a99.
• Supercontest.
• Week 4 did not become available at 10am PT, which would have been the case if I had messed up the timing (because that's 5pm UTC).
• Restructured almost all of core/results, and its corresponding usage in views, to be sequential. Query for something, pass it to something else, sort it, calculate from it, etc. It's a much clearer, layered approach now. The analytic functions are modular, no queries are being repeated. Establishment of the necessary information happens FIRST, in the route, in the highest level. It's much easier to see duplicates now.
• This modularity made my query footprint a lot smaller. The all-picks view would query for all users but only one week, whereas the lb/graph would query for all users for all week. They used the same machinery underneath, but the latter called it in a loop. Now it queries all at once and reformats the data as desired after. I remember thinking about this inefficiency when I first wrote it, but didn't have time to optimize. I do now.
• Commented out all the tests so that I can run test-python to completion as it should. All no tests run, it's still gives more information to add this properly to my dev workflow (it compiles requirements and such).
• Tested and work. App is a lot snippier, and FDT shows a lot fewer queries (like 10 max, for the worst route that has to query everything).
• Updated to harner's gif. Played around with the background css styling. There are two important ones: background-repeat and background-size. "space" will keep the original size but fill in gaps with whitespace, "round" will distort the image within a slight margin to fill the gaps (both for repeat). For size, you can basically stretch it or keep it the same, fit in parent, etc. Looks good now. Fits one across on mobile, and repeats on larger viewports.
• Made the app gracefully handle the time period between 5pm PT (week_start) and when westgate posts the lines, if there's a delay. It conditionally shows messages, and even omits the table.
• The heaviest (time-wise) route in the main navs is /graph. The heaviest league is the free one, because it's the least filtered. And the heaviest season is any full one. Therefore, the current view that takes the longest to load is https://southbaysupercontest.com/season2018/league0/graph.
• Removed wednesday from RESULTS_DAYS and just added a single commit_scores call within commit_lines, so it initializes properly.
• Added queries.is_user_in_league and g.user_in_league.
• Fixed a few things to make the new "return empty but valid results for new lines and new picks" work.
• Confirmed that newly committed lines from westgate enter the db with timezone info, and timezone = utc (the rest were manually added to the migration - I wanted to make sure it was consistent.
• Did the usual wed deployment.
• If you follow a ctag in vim, don't edit it there. It won't save by default. This is just for looking.