Mostly Software

  • Wednesday

    • Private work.
    • Python’s sort() function uses Timsort, which is (worst case) time O(nlogn) and space O(n).
    • Reset zoom on vscode. I had been zoomed IN (just one click) for years, but it’s unnecessary strain on the eyes.
    • Macbook launchpad keyboard shortcut continues to be broken. Pinch with thumb and three fingers instead. You can also spread with thumb + 3 fingers to go to desktop. F4 is spotlight, but full launchpad view is better.
    • To list versions of installed pkgs on ubuntu: apt list -a <>
    • Updated docker desktop on macbook.
    • Order dutch crunch rolls online! https://dutchcrunch.com/collections/all
    • Windows cumupdate.
    • You can export a backup from rds to s3.
    • Got jury summons. Requested first-time postponement, 6 months (max).
    • Supercontest.
      • Uninstalled postgres14 on the ec2 instance (came native with ubuntu). Also did some apt purge/autoremove/upgrade. Then reinstalled postgres15 and rebooted. Couldn’t find JUST the client (psql/pg_dump/pg_restore) in v15.
      • Reserved Instances.
        • “Reserved DB instances are not physical instances, but rather a billing discount applied to the use of certain on-demand DB instances in your account.” Your usage on an instance comes in. You get charged for storage, backups, other side items. And then you’re left with the hourly rate for the instance. If you have an RI that matches the specs of that instead, your hourly rate is at the lower RI price. If not, you pay full on-demand price.
        • For example: Take a single az, rds (not aurora), t3.micro. Storage and backups are a couple dollars a month each, and those are the same in both cases.
          • On Demand: 0.024/hr, or 17.52/mo. No upfront.
          • RI: 0/hr. Upfront 294, or 8.17/mo.
        • This is all the same as EC2. My RI was 315 upfront (8.75/mo), 0/hr usage charge. And then for storage etc, there’s a little extra.
        • So every RI for both EC2 and RDS is about $8/mo (all upfront), and then maybe $4/mo for the peripheral usages.
        • Created case to remove the second RI: https://support.console.aws.amazon.com/support/home#/case/?displayId=14308599831&language=en. I’ll just use local docker-compose with pg for dev. He was able to cancel it for me, but this will occur at the end of the billing cycle (EOM).
      • I’d like to use RDS’ blue/green capability. It handles the syncing for me. Upgraded the prod rds from 15.3 to 15.4 and created parameter group with rds.logical_replication=1 and associated it with the instance. All required for blue/green. Gonna test it for a bit, check costs to ensure green instances are covered under RIs, and decide to keep (or just create another dev instance and manage it directly).
      • Accidentally deleted the prod ec2 db container. Last backup was thursday of last week. Had to manually recover picks and scores.

  • Tuesday

    • Private work.
    • Browsers do not count for netflix devices.
    • Finished The Fall of the House of Usher. Flanagan is so good.
    • Garden maintenance.
    • AWS product refresher.
      • App Runner is kinda like Elastic Beanstalk. It’s a all-in-one service for “I have an app and don’t care about the infra, just deploy/manage it for me.” EB is comprehensive. AR is only for containers.
      • SAM = Serverless Application Model. It’s a template for building a serverless stack on aws.
      • There’s also SAR = Serverless Application Repository. Integrates with Lambda.
      • Remember storage options: Glacier, S3, EFS, EBS.
      • Boto is the python SDK.
      • Chalice is AWS’ platform for python serverless applications. It’s an aggregator, like the others. With SDK/CDK integration. Define your web routes, your schedules, your s3 triggers, your lambda functions, whatever. https://aws.github.io/chalice. Pretty cool tool, although I don’t think I’ll keep the API backend in python for much longer, so I don’t want to marry to a python platform.
      • DevOps guru does some pretty cool ML-based anomaly detection for services like RDS. Costs a few dollars a month.
    • Lambda dive.
      • Most stemming from the large tree of https://docs.aws.amazon.com/lambda/latest/dg/welcome.html.
      • Entry point is always lambda_handler(event, context). Event is the (json) data passed by the caller. Context is env, arch, logs, etc.
      • You can do cool stuff like trigger from s3; every time an image is uploaded, it creates a thumbnail and adds that to s3 as well. I could use this for the sbsc banner.
      • You can do some advanced stuff later. Testing functions in the cloud. Added traces.
      • The default artifact of a lambda created from the UI is a zip archive. You can include OTHER libraries, dependencies. And you can organize them in layers for efficiency. Example on https://docs.aws.amazon.com/lambda/latest/dg/python-package.html.
      • If you want to bypass all that, you can just deploy one of your containers as a lambda. Then it’s not lambda_handler, it’s the docker ENTRY_POINT.
      • If you’re not plugging a lambda into another service and triggering on some event-driven flow, you can invoke the lambda directly via the UI or CLI. You can ALSO assign a function URL and call it to invoke a lambda.
      • Use CDK + CloudFormation to define lambdas from source and autodeploy them. Fun fact: cloudformation is declarative (as you’d expect) but CDK is imperative! It converts your instructions to a finish line.
      • There are tons of third-party extensions for lambda: datadog, splunk, sentry, etc (if you don’t want to use internal services like cloudwatch for these)
      • Lambdas don’t have a connection pooling mechanism and make lots of short connections. This is exactly what RDS proxy was built for.
      • Your lambda functions can use IAM permissions to connect to the DB. Much better than UN/PW, etc.
      • Full RDS example: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-lambda-tutorial.html.
      • Another example with Aurora: https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/python/cross_service/aurora_rest_lending_library
    • Supercontest.
      • Probably the best E2E tutorial for a webapp: https://aws.amazon.com/getting-started/hands-on/build-serverless-web-app-lambda-apigateway-s3-dynamodb-cognito/. Amplify, API Gateway, Lambda, Cognito, Dynamo. Pretty close to my supercontest stack.
      • Closed docker image build ticket (https://gitlab.com/bmahlstedt/supercontest/-/issues/165) – I’m gonna do serverless. Frontend = amplify hosted. Backend = lambdas. Will handle the remainder on the respective tickets for react and compute.
      • Cognito and SES (and most of the rest of the infra) is in us-west-1. Pinpoint and SNS are in us-east-1. Hopefully this doesn’t cause any issues.
      • When I sell the EC2 RI later (once fully serverless), aws marketplace takes 12%.
      • Since the lambdas hit the db through rds proxy (not connection-pooling through flask anymore), I have to finish #188 first.
      • RDS.
        • Current EC2 node is t2.micro. And it runs 3 containers, only 1 being postgres. So t3.micro for the db is plenty.
        • RDS Postgres calculator: https://calculator.aws/#/addService/RDSPostgreSQL
        • Aurora Postgres calculator: https://calculator.aws/#/addService/AuroraPostgreSQL
        • Scenarios (order of modern-ness)
          • Aurora serverless v2, 0.5ACU/hr (min), rds proxy, 10GB storage, 10GB backups = $175/mo
          • Aurora serverless v1, 2ACU/hr (min), 10GB storage, 10GB backups = $115/mo
          • Aurora non-serverless, 1 instance, t3.medium, RI 3yr upfront, rds proxy, single az, 10GB storage, 10GB backups = $60/mo (35 from the upfront, only 25/mo recurring)
          • RDS, 1 instance, t3.micro, RI 3yr upfront, rds proxy, single az, 10GB storage, 10GB backups = $35/mo (10 from the upfront, only 25/mo recurring)
        • RDS proxy is more than HALF the cost for the prices above. For aurora serverless v2, RDS proxy is ~115/mo (at min of 0.5ACU/hr, min of 8ACU charge). For the non-serverless solutions, it’s ~$25/mo (at min of 0.5vCPU/hr, min of 2 vCPU charge).
        • Serverless WOULD be cheaper than my RDS because 0.5ACU/hr is a pretty small workload. BUT, supercontest is even less than that, so the serverless minimum is greater than an always-on RDS instance. This is the only piece of the app that isn’t scalable at the end of the cloud migration. As traffic increases, the db should be converted to aurora serverless v2. https://gitlab.com/bmahlstedt/supercontest/-/issues/226
        • Bought the RI, 3yr, upfront, single az, $294. Created the DB as above. Non-aurora, non-serverless, postgres15, db.t3.micro, existing master un/pw, 20GiB gp3 SSD, auth via pw and IAM, rds proxy.
        • Will add elasticache later: https://gitlab.com/bmahlstedt/supercontest/-/issues/225
        • Backups daily (6am ET). Maintenance weekly (tuesdays 7am ET).
        • There’s DMS = Database Migration Service. Designed for tasks like this, getting another DB into RDS. I wanna see the lowlevel cloud db details, so I’ll do it all manually.
        • Actually no – deleted the RDS proxy. I get low traffic for this site, not worried. Postgres default connection limit is 100. I’m not gonna have 100 concurrent lambdas until the userbase substantially increases. Added to #226 for future.
        • The version of psql/pg_restore/pg_dump must match between server (rds) and client (where you’re running the above, either localhost or ec2 instance). Therefore, you’ll need pg15 installed.
        • You can attach a security group which allows postgres traffic inbound (tcp, port 5432), as opposed to an EC2 or Lambda connection, but it still won’t work. You have to change the db config in rds to be publicly accessible.
        • All explicit targets should go to lambdas, and have explicit lambda connections in rds. Open-ended psql can be accessed from EC2, for now – when I’m fully serverless later, I can open up public access to the DB (at least dev).
        • Got psql / pg_restore / pg_dump working with the cloud db.
      • Updated banner.

  • Monday

    • Private work.
    • Dot product in python is easy: sum(a*b for a, b in zip(a, b))
    • Hawaii NYE planning.
    • Paperless post has SUCH bad interfaces. Surprising for one of the top premium invite services? Best way to get sharing is just add yourself as a guest, then use the texted link to forward around. Then you don’t have to generate the universal share link for 200 coins.
    • Charge kindle from the desktop, not the free micro usb cable.
    • Aquarium maintenance. Some meal prep.
    • Created gitlab project and ticket for the app catalog: https://gitlab.com/bmahlstedt/app-catalog/-/issues/1
    • Supercontest.
      • Lots more work on api gateway.
        • Played with passthroughs of path params, query params, and payload JSONs.
        • Diff stages, manifesting as paths, abstracted since you’ll put CF in front of the full API Gateway URL.
        • Built a full example of private access. API Gateway -> VPC Link -> NLB -> ALB -> EC2. Any path in apigw can use this. Just very clunky and double price (both ELBs).
      • I don’t need the EC2 public IP. It’s just a convenience (ssh.<domain> -> ec2.<domain> -> elastic IP) to ssh sbsc from the command line. Come next year (before they start charging), it’ll be gone anyway as I’ll have migrated all of compute from EC2 to Lambda.
      • Cleaned some old resources. RDS subnet group. Unused security groups and network interfaces (largely autocreated by RDS).
      • Ultimately decided to migrate everything to Amplify/APIGateway/Lambda/Cognito.

  • Sunday

    • Private work.
    • Installed java8 on macbook.
    • AppSync.
      • AWS’ serverless graphql api tool. Like apigateway for rest.
      • Define schema, test queries in the interactive console, custom domains, everything you’d expect.
      • Really nice for cases where you’re combining data from multiple sources: rdb, lambda, http apis, etc.
    • Played with graphql.
    • Ordered all friendsgiving stuff.
    • Amplify E2E.
      • Install amplify cli (npm pkg in your app). Created IAM user, added amplify-admin policy, created access key, configured CLI to auth with that user. These are stored in ~/.aws/credentials. You can have multiple local profiles. ~/.aws/config is there too, which defines zone and such.
      • Use the cli to init. Deploys resources to support amplify. Like creating a new app in amplify studio.
      • Install npm pkg aws-amplify for frontend libs.
      • amplify add api, define type (graphql/rest), define auth (key, cognito, etc), define schema. It can also autogenerate code for you (CRUD operations, like graphql mutations/queries, rest gets/posts, etc).
      • amplify push for just backend, amplify publish for both backend and frontend.
      • CloudFormation is obviously the default provider that amplify’s CLI uses for creating/managing the cloud resources. For the API, AppSync is used for GraphQL and APIGateway is used for REST.
      • amplify console api opens up your API’s console in the browser (the aws ui), appsync for graphql and apigateway for rest. amplify console opens up the full console (amplify studio).
      • amplify mock api will spin up a local graphiql server to test your api (interactively). I think it spins up a local db too so you’re not writing to the cloud db.
      • Testing the app locally (npm start) will still connect to your cloud db! Make sure it’s in the env you desire. For dev, have a dev setup (duh).
      • amplify add auth. Define some cognito basics (federation/socials, un/ph/em/pw, etc). Then you just add some components / auth wrappers to your frontend.
      • Then users can create accounts, confirm email, login, etc. Everything you wanna do. These changes are synced with cognito. Played with this a bit.
      • There are many other components in @aws-amplify/ui-react. You can use these, style them, customize them, combine them with yours, whatever.
      • Add hosting. You can use amplify native to host a node env where the app runs, or you can do a custom setup with cloudfront and s3. Amplify just speeds a lot of this up for you (while still using cf and s3 under the hood), and allows CD by plugging into your git repo, etc.
      • publish will gzip the assets and deploy an optimized production build to your hosting env. I’m sure you can customize this to use whatever bundlers/minifiers you want.
      • REST.
        • You basically add paths and corresponding serverless functions. These go to API gateway and lambda.
        • You can separately have unauthed paths and authed paths. The authed paths integrate with cognito.
      • For amplify add storage, you only have s3 and dynamodb options.
    • Lambda layers are reusable bits of code/assets available to other functions. Imagine a python module you wanna import to two lambdas. Or a node_modules dir you wanna use across multiple functions.
    • Supercontest.
      • Pinpoint’s tollfree registration finally came back (after 2 weeks) and said “company website is not accessible” (bullshit). Updated/resubmitted the registration to /user/register to make it obvious…that of course the site requires login. That’s literally the point of the registration process, to affirm user flows before comms are provided.

  • Saturday

    • Private work.
    • UFC 295 at MSG.
    • Bowery Hotel (Only Murders event was a scam).
    • Saw Jason Momoa.
    • Remember: Pointers in your brain are efficient. If someone has a billion verbosities committed to memory (or full algos memorized for DS&A, creative arts, whatever), retrieval for other RAM is slower. Store a pointer. Look it up later.
    • Amplify charges in two segments. Build/deploy time, 1 cent per minute. My build is only a few seconds, and I’ll probably only do a couple rollup commits per day. The second segment is hosting. 20c/GB stored (build output size, times number of builds, factor in expiration), 15c/GB served, 30c/1M requests, 20c/hr request durations.
    • Did a ton of planning for parents trip.
    • Ordered friendsgiving food.
    • Escape Room.
    • ABC kitchen.
    • Cloudshell is aws’ cloud CLI. Injects creds and a lot of other things for simplification.
    • A bit more on Amplify.

  • Friday

    • Private work.
    • Remember (cassandra java) (scylla cpp). Both nosql.
    • Anthony Jeselnik at Carnegie Hall.
    • OpenAI seeking data partnerships: https://openai.com/blog/data-partnerships
    • NY map: https://www.nytimes.com/interactive/2023/upshot/extremely-detailed-nyc-neighborhood-map.html
    • The longspine urchin ate the molt of the sally lightfoot crab!
    • I get so many spam calls nowadays.
    • Ordered fresh. Turkeys were anywhere from $2-5/lb at morton williams. $1/lb for butterball on fresh / whole foods.
    • Next.js useful reminders. Most are obvious.
      • SSR is still valuable if your app is purely a client that hits other servers/APIs you don’t own. SSR runs wherever next.js runs; in my case, the amplify hosted env. That’s where we get the SEO/Perf/Fetching benefits. Not the data server / API server.
      • You can host html/css/js in s3. The client browser knows how to render it. You can also return it directly from the api server. Next is much smarter – the client browser requests, the app hosting env is running next/node and can do a bunch of serverside actions. Fetching. Caching. Rendering. Whatever. This speeds up the client. 
      • App router (new) vs page router (old). It’s filesystem based. You can also have dynamicism (eg `=[routeFolder]).
      • By default everything from fetch() (server-side only) is stored in a data cache (in amplify, vercel, wherever it’s hosted). If you want to fetch from the client, use Route Handler (or third party libs like swr https://swr.vercel.app/). Try to lean toward doing datafetching serverside though. Then you can store db connections, api tokens, etc, there and not expose to the client. Also, serverside means you can cache responses across users, which you cannot do clientside (single user).
      • “Deploying” is pushing the app to that serverside env (not api server, not client). It’s running next and node.
      • Remember the browser immediately shows your html (non-interactively) on initial page load, then hydrates everything with js instructions.
      • Serverside rendering can occur in a few places. Static rendering is at build time (for pages like docs, feedback forms, etc). Dynamic rendering is at request time (eg for user-specific views). Next will automatically choose the best rendering method for your pages (based on the functions used). There’s also Streaming rendering, which is basically just where the data is chunked.
      • Clientside rendering is best for interactivity. You can useState(), useEffect(), event listeners. I probably don’t need any client components for sbsc. Maybe for something like statistics, where it fetches everything at once then the client chooses the dropdown filters. I might need a client component for the matchups view too, where onClick() is needed for picks.
    • Supercontest.
      • Looks like most of the amplify cost is in the build time (for my relatively low request service). In steady state, I’ll just have builds on master and staging (not feature branches? or just on pull requests).
      • More tinkering in amplify studio.

  • Thursday

    • Private work.
    • GitHub Universe Keynote: https://www.youtube.com/watch?v=NrQkdDVupQE
      • Of course MS, same OpenAI umbrella.
      • Focusing mostly on AI pair programming with Copilot, coming December.
      • Plugs into github itself too; eg asking chatgpt to write a PR summary for you.
      • Automatic scans for security reviews, plaintext passwords.
      • Regex assistant.
      • You can train copilot on your company’s private data. Copilot Enterprise. Example: if you have an internal service to do something, copilot can suggest that instead of a public solution. Example: explain code XYZ to me.
      • Copilot Workspaces. For every issue filed on github, it will analyze it (and the repo, and the internet) and propose a solution and PR the fix.
    • Copilot.
      • Unistalled tabnine and installed copilot (+chat, +labs) for vscode. Signed up for individual ($100/yr, 1mo free trial). Labs requires an extra term agreement (free).
      • Autocompletion is great. Has multiple suggestions you can scroll through (alt and a bracket, left or right)
      • ctrl-i for (editor-inline) copilot chat. Ask it to create all sorts of code. Instead of inline, you can have a full chat window open in the sidebar (basically chatgpt in ide).
      • You can also just write comments and tab through the autocompletions to generative code step by step.
      • The Labs sidebar has 4 features.
        • Explain highlighted code.
        • Translate highlighted code (to another language).
        • Generate tests for highlighted code (only available in js/ts for now).
        • And a bunch of “brushes” – add docstrings, add types, chunk into smaller functions, clean, make readable, more.
      • After 1 day of use – this is extremely helpful in speeding up development times. Especially for less-familiar areas, like my tsx sbsc translation.
    • NYT definitely uses wordpress for their site. After looking it up, so does Forbes, CNN, many more.
    • Updated iCUE.
    • Can’t simply fetch() in useEffect to an address with a CORS policy that hasn’t whitelisted your requested origin (like localhost for testing -> sbsc). Must set the response headers on the server itself (not a clientside fix, obv). Postman doesn’t hit these errors bc it’s just sending the request. Browsers enforce CORS policies (and requests submitted from apps running within them). Exception: the navigation bar doesn’t enforce CORS. These are considered basic requests, unlike XMLHttpRequest/AJAX/FetchAPI.
    • Remember server components can’t useState or useEffect.
    • Monthly water change AND biweekly maintenance. Replaced trident reagent A.
      • You can’t fill the sump all the way up to the top of the white divider. It will overflow when the main pump is off.
    • The AWS vscode plugin allows you to interface with all your aws resources. You can modify files in s3, invoke lambdas, check cloudwatch logs, more.
    • Omegle was forced to shut down (mostly child abuse).
    • Updated vscode.
    • Mint is being shut down.
      • Moving to Credit Karma.
      • Another product under the Intuit umbrella.
      • Not sure why. Mint is such a popular aggregator.
    • Disputed the “undeliverable” charges on the prime card. Amzn hadn’t issued a refund, and the charges are still posted to the account.
    • Amplify.
      • Amplify has been costing the privateer site less than a cent per month (low traffic, no big changes to rebuild).
      • There’s Amplify Studio and Amplify Hosting. The latter is for hosting the frontend, which I need. Studio is huge:
        • Assists with building the fronted. Library of UI elements.
        • Defines data model.
        • Storage.
        • Managers users / authentication.
        • Analytics.
        • API definition (REST and GraphQL).
      • Amplify automatically creates a CF dist and DNS records to front your app.
      • While Studio is basically the IDE for the full stack; you can also use the console, `amplify-cli`.
      • You can’t migrate an amplify app across regions (easily).
    • Supercontest.
      • Worked on Amplify all day today.
      • Dumb refresher. In the early years, my sbsc site was basically SSR. Flask would get the requests and respond with the rendered templates. But you can just as easily deploy a static site (SPA or otherwise, it’s just a collection of html/css/js files) to s3/cloudfront. Nowadays, Amplify supports SSR via next.
      • Currently using flask-user, and migrating to aws-cognito, but I could also move to flask-jwt-extended. You just make a /login route, take the un/pw, use the jwt lib to create a token from it, then return the token to the user. Subsequent async requests from your client app to the server can use the jwt.
      • Versioning.
        • This was entirely too difficult for such a commonly used modern stack of amplify+next. You can’t use node 20, which is LTS.
        • At first (node 20, npm 10, next 14). Ran into too many issues with the default build image, pkg overrides, GLIBC_2.27 not found, etc.
        • Switched to (node 18, npm 9, next 14). Still facing issues.
        • So just used the build image public.ecr.aws/docker/library/node:20. Build passed, failed on deploy (for the hosting env, not backend).
        • Found this: https://github.com/aws-amplify/amplify-hosting/issues/3773#issuecomment-1783092708. The fix lies on the amplify side. As of 2 weeks ago, amplify only supports node 16 (!!).
        • Then it looks like the devs added support for node 18 (which is compatible with next 14) last week. Node 20 is still not supported.
        • Honestly considering moving to vercel purely to avoid this.
        • Eventually got it working with node 18. Can’t add package overrides (since still missing glibc in amazon linux 2), so set custom build image to public.ecr.aws/docker/library/node:18.
      • Next obv ships with ts, eslint, tailwind.
      • Yep, Amplify has UI components (and cognito integration) to replace everything from flask-user.
      • https://aws-amplify.github.io/amplify-js/api/classes/authclass.html