• 6 Posts
  • 89 Comments
Joined 1 year ago
cake
Cake day: June 7th, 2024

help-circle


  • A long time ago I helped set it up so an elderly relative’s HOA dues were auto-withdrawn from their checking account. Someone stole one of their checks, washed it, wrote in a different name and amount, and cashed it. Bank anti-fraud caught it, refunded the money, and closed the account. I sent the HOA a message explaining the situation and asking what the procedure was to change account numbers.

    They emailed over an attached PDF form. Had space for fullname, phone, address, bank routing and account number, and her real signature. Pretty much a PII nightmare. The instructions were to have it filled out and emailed back to them. 🤦🏻‍♂️

    Told the relative to print it out and send it back by post.











  • Shades of dotcom days. Everyone hopped on the bandwagon. Most lured by the high salaries and gold-rush mentality. Nowadays, just having a CS degree isn’t enough. You want portfolio pieces to set you apart. Start by having a damn portfolio. You can set one up for free on GH Pages or CloudFlare. Or pay a few bucks and set one up on Wordpress. If you can’t figure out how, that CS degree was wasted.

    You want stories that show you bring value. Show that you can build things beyond school projects. Even if you do school projects, document them and push them out. Show why they’re cool and what you can do. Throw up screenshots, diagrams, or animations. No walls of text.

    Also, learn to sell yourself. Not in the oily LinkedIn way. Just be out there. Contribute back. Educate others and have a voice. Blog, newsletter, social media, book, or video channel. They’re dead-easy to set up and free so there’s no gatekeepers to go through, other than your ideas.

    If in a big city, go to Meetups or demo days. Meet people and ASK WHAT THEY DO. Help connect them to others. Anyone just sitting there cranking out resumes is going to get filtered by the LLM screener. Might as well pin up your resume above the urinal at the pub.

    Finally: everyone can low-code or vibecode. Those are table stakes now. You want to do better.








  • A few suggestions:

    • Some of those components may end up costing a lot to operate. You said you’re doing it as a portfolio piece. May want to create a spreadsheet with all the services, then run a cost simulation. You can use the AWS Cost calculator, but it won’t be as flexible doing ‘what if’ scenarios. Any prospective employer will appreciate that you’ve given some thought to runtime pricing.

    • You may want to bifurcate static media out and put them in S3 buckets, plus put a CloudFront CDN in front for regional scaling (and cost). Static media coming out of local server uses up processing power, bandwidth, storage, and memory. S3/CloudFront is designed for just this and is a lot cheaper. All fonts, js scripts, images, CSS stylesheets, videos, etc. can be moved out.

    • Definitely expire your CloudWatch log records (maybe no more than a week), otherwise they’ll pile up and end up costing a lot.

    • Consider where backups and logs may go. Backups should also account for Disaster Recovery (DR). Is the purpose of multiple AZs for scaling or DR? If for DR, you should think about different recovery strategies and how much down-time is acceptable.

    • Using Pulumi is good if the goal is to go multi-cloud. But if you’ve hardcoded Aurora or ALBs into the stack, you’re stuck with AWS. If that’s the case, maybe consider going with AWS CDK in a language you like. It would get you farther and let you do more native DevOps.

    • Consider how updates and revisions might work, especially once rolled out. What scripts will you need to run to upgrade the NextCloud stack. What are the implications if only one AZ is updated, but not the other. Etc.

    • If this is meant for business or multiple users, consider where user accounts would go? What about OAuth or 2FA? If it’s a business, they may already have an Identity Provider (IDP) and now you need to tie into it.

    • If tire-kicking, may want to also script switching to plain old RDS/Postgres so you can stay under the free tier.

    • To make this all reusable, you want to take whatever is generated (i.e. Aurora endpoints, and save everything to a JSON or .env file. This way, the whole thing can be zapped and re-created and should work without having to manually do much in the console or CLI.

    • Any step that uses the console or CLI adds friction and risk. Either automate them, or document the crap out of them as a favor to your future self.

    • All secrets could go in .env files (which should be in .gitignore). Aurora/RDS Database passwords could also be auto-generated and kept in SecretsManager and periodically rotated. Hardcoded DB passwords are a risk.

    • Think about putting WAF in front of everything with web access to prevent DDOS attacks.

    This is a great, learning exercise. Hope you don’t find these suggestions overwhelming. They only apply if you want to show it off for future employers. If it’s just for personal use, ignore all the rest I said and just think about operating costs. See if you can find an AWS sales or support person and get some freebie credits.

    Best of luck!