·Chatter

Little Warnings

Stuff to look out for

It might just be my social media algorithm, but nearly all of the posts I see now are about vibe coding and "I'm making $20k+/month and I barely lift a finger", and "I just one-shot the next Salesforce", and "I just built and published this on the Play Store in 2 days". While the enthusiasm is great, there are some things newer people to the world of coding need to know. I'm not gatekeeping, this is for your own benefit!

Rule #1

If you're doing an app with a backend or reaching out to some service, be it Gemini API or Supabase or whatever (shout-out Supabase!), you should know that best practice is to put your API keys in one of those .env files. If you're using a file like that to hold API keys or anything else you'd consider secret, ABSOLUTELY DO NOT EVER commit that file to GitHub or whatever other version control you use. Even if your repository is private, it's terrible practice and one day will result in your API bills skyrocketing because someone, malicious or otherwise, found your secret keys. Private keys committed to a public repo become public keys, and not in a good way.

Rule #2

Make sure your code can actually handle errors. Sometimes AI code output is optimistic and assumes everything will always be alright. This is called the "happy path". But you won't be happy if a user sends some input that your app does not know how to deal with and falls apart. Make sure database calls, API calls, whatever you're passing data to can handle errors gracefully.

Let's say you have a database field, meant to store an email address, which takes 40 characters. Somebody sends an email address with a 42 character length, and without error handling or validation it gets sent to the database and you'll get a SQLException back, and no knowing what happens after that. There's even the risk that unhandled errors get returned to the client with more technical detail than you'd like, and it might expose some details would-be attackers might be interested in. Speaking of SQL and validation...

Rule #3

SQL Injection. This is a big one. No introduction to SQL injection is complete without meeting Bobby Tables. Say a user inputs this into a login field: '; DROP TABLE users; --

Besides the obvious bit you can read, this is doing a few things. First is ';, which closes the part of the query your input was going into. Second is dropping the users table. If there's no key constraints or anything tying it to another table that might rescue it (a time when a SQLException would come in handy), then it's gone without any yes/no confirmation prompt. Finally is --, which renders the rest of the original SQL statement into a comment, so it never gets executed. If your code just pastes that into a database query without any validation, and your table is actually called users, you're in trouble. Database table's gone. Make sure you use prepared statements and make sure you're protected against injection vulnerabilities. Don't skip this one. I can guarantee it'll all end in tears for someone who didn't know the fundamentals.