• Wednesday

    • Private work.
    • WP.
      • Updated wp to 6.4 (and plugins).
      • Updated theme 2015 -> 2024. FInally got the editor indentation back.
      • Remember the primitives: posts, pages, media, comments. I don’t use comments. I use posts and media. And now I split segments into pages for ease of use.
      • Created pages: About, Archive. Then there’s the default “Blog Home” which shows recent posts as the homepage.
      • Edited footer (template) to just be copyright.
      • Customized header. Site logo, site title, pages, search.
      • Removed author name, category, etc from the Post Meta template. Just Date and content. Title goes around the meta (the calling template).
      • Remember – you have to specifically link a link in the post editor, you can’t just copy a URL. Just highlight the link and click the paperclip. Example: https://gitlab.com/bmahlstedt
      • Created new template part Posts Query Loop for use on Blog Home and Search Results (note this fixed the search inconvience, now shows full posts on results page).
      • Also added this new part to the other templates that show posts: Archive (day, month), Index.
      • Edit button on individual posts is gone? Just go through admin interface.
      • One last little nit: the bullets in editor mode are normal and the bullets in the viewer (published) are reversed (clear is level one, solid is level two, etc).
      • Media library does not allow ico or svg – use jpg or png.
      • Installed a vanilla plugin to highlight search terms in the results.
    • You can obviously connect a webapp directly to a db. Faster to prototype. But at scale (and for safety), the frontend should talk to the backend via a rest api, and the backend maintains the db connections. You can pool, make queries efficient, cache, check auth – many things that are harder / impossible / spoofable on the frontend.
    • AWS.
      • Remember AWS Pinpoint tollfree registration can take up to 15 business days. That ends Nov 24 for me.
      • Bunch of research on AWS API Gateway.
        • Swagger, methods, CORS, massive amounts of customization, deployment stages, custom domains, integration with cognito, integration with lots of compute backends (lambda is most supported), ability to generate SDKs from the API definitions, testing, versioning.
        • Great choice for API dev/mgmt. Overall; the value is truly in the definition of the API. Right now, it’s just living in the flask routes. API gateway gives it structure, standards, stages, versioning. All the desires of an at-scale API management process.
        • This is also deeply tied to compute. The value of APIGW is extracted much more greatly if the microservice model is employed with Lambda functions as the serverless backend. It’s more cheap and atomic than ELB -> EC2.
        • Note on cloudfront: if you build a REST API in APIGW and choose edge, it will create a managed CF dist for you. Both work in tandem.
      • Outposts = on-prem deployments.
      • Compute. ECS is much cheaper than EKS (which costs $70/mo just for control plane). ECS is cheaper than ELB/EC2 ($18+/mo). Fargate is the serverless deployment (for both).
      • Elastic Beanstalk.
        • It’s an aggregator. Can define your backend server, what env/lang/version, attached RDS, nginx revproxy, load balance, logs to s3, maintenance windows, CW integration, security groups / IAM users / policies.
        • This is very nice for users who don’t want to learn the details of the aws stack/offerings. It’s a single entry point to deliver a full-stack application, and EB handles the infra under the hood for you.
        • Since I’m already managing all those components, I’ll stick with Amplify/Vercel for the frontend deployment.
    • Iphone’s “repeated calls” setting is >= 2 calls from the same origin in 3min. Disabled this for DND and Sleep.
    • Supercontest.
      • Currently, compute is ELB/EC2. Considering moving to Lambda/APIGW. Or ECS/Fargate.
      • The pricing for ELB is fine after the scoreticking change. It’s not the traffic that is the expensive piece (although that scales), it’s simply the $18/mo for the ALB.
      • Did some planning. Order the remaining tickets, gates, and do-togethers.
      • Updated banner.
      • Genericized banner (without extension) so that I can upload gifs or jpgs or pngs or whatever week-by-week format I want.
      • Started designing the backend/frontend splitout.
      • SELECT CURRENT_TIME; in psql to verify the week rollover is good after DST.
      • Made it so the table-specific actions (ranks, highlightUserRow, setInterval for scoreticking, etc) only occur on (1) the matchups view when lines are committed and there’s an actual matchups table and (2) the allpicks view when picks are closed and there’s an actual allpicks table.
      • Fixed some /pick functionality (mostly from jquery removal).
      • Verified that the scoreticking changes were good on week rollover as well. If you leave a tab open before week rollover, it will keep fetching the old week after rollover (as intended).
      • The metric filter for app container log alarms was triggering on a gunicorn log msg: [WARNING] Exception managing chrome: Unable to discover proper chromedriver version in offline mode. This doesn’t matter. Changed the filter to only trigger on my errors, ?ERROR ?CRITICAL ?EXCEPTION.
      • The commitScores lambda failed during redeploy, that’s fine (remember the logic to NOT commit scores is serverside, the lambda fires 24/7).
      • The commitLines lambda failed. The function behaved normally (lines committed, email went out), but the lambda logs showed timeout. It defaults to 3s. My server doesn’t return that quickly for the commit-lines route (webscrapes, writes, emails, more). Increased the timeout for all 4 eventbridge lambdas appropriately.