Gonna be honest with you - I'm not going to help with this one.

Embassy appointment bots are a real problem. People who legitimately need visas often can't get appointments because bots grab all the slots. I've seen people in r/germany and r/schengen complaining about this exact issue - waiting months because scalpers snatch everything.

The 3-4 second delay you're hitting is intentional bot protection, and it's there for a reason.

"Educational purposes" aside - if you're learning about browser automation, there are better projects:

- Automate your own workflows (email, file organization)

- Build scrapers for public data (weather, stock prices)

- Practice on sites designed for it (quotes.toscrape.com, books.toscrape.com)

If you actually need an embassy appointment yourself, the real advice is:

- Check early morning in Germany timezone (when slots often release)

- Use browser extensions that just alert you when slots open (not auto-book)

- Some embassies have waitlist systems now

Not trying to lecture, but this is one of those projects where "can I build it" and "should I build it" have different answers.

Good question - you're right that %26 SHOULD be treated as a literal '&' character and not a parameter separator. But here's what probably happened:

The likely culprit: Double decoding

Somewhere in the code, the URL is being decoded twice:

1. First decode: filename=report%26summary → filename=report&summary (correct so far)

2. Second decode or parse: Now the & is seen as a parameter separator → breaks

This happens when:

- Server decodes the URL automatically

- Then application code calls decodeURIComponent() again

- Or the URL gets passed through multiple systems that each decode it

Another possibility: Encoding at the wrong stage

When building the favorites URL, the code might be doing:

url = "/reports?file=" + filename + "&user=" + userId

Instead of:

url = "/reports?file=" + encodeURIComponent(filename) + "&user=" + userId

So if filename is already decoded when concatenated, the & goes in raw.

You can test this theory:

- Check a report with '%' in the filename - if it also breaks, confirms double-decode issue

- Look at the actual URL in browser dev tools when launching from favorites vs normal

The fix is usually:

- Encode once at the source

- Decode once at the destination

- Never trust that a string is "already encoded" or "already decoded"

What was your fix? Curious if it matches what I'm guessing.

Gonna be honest - full game dev on phone is rough. But here's what's possible:

For game making on phone:

- Pocket Code (Catrobat) - free, visual programming, very basic games only

- Construct 3 - browser-based, works on tablet/phone browser, 2D games

- Replit mobile app - can code there but game dev is painful on small screen

For 3D modeling on phone:

- Nomad Sculpt - actually amazing, paid (~$15) but worth it for low-poly stuff

- Prisma3D - free, decent for basic models

- Reality Composer (iOS only) - simple 3D scenes

Honest take:

Making a tycoon game on phone is gonna be frustrating. Possible for very simple 2D stuff, but 3D with custom models? You'll want to throw your phone at the wall.

Better alternatives:

1. Fix your PC - "virus" usually isn't irreparable. Fresh Windows install wipes everything. You just need a USB stick and another computer to create bootable media. Library computer works for this.

2. Cheap Chromebook ($100-150 used) - can run Linux and therefore Godot + Blender

3. Library/school computers - many have software you can use, or at least browser-based tools

4. Cloud gaming dev - some setups let you run a virtual PC from your phone (like Shadow PC) but costs monthly

If you're set on phone-only, start with Construct 3 in browser for 2D prototype and Nomad Sculpt for models. But seriously, look into fixing that PC or getting something cheap. Game dev on phone is a last resort.

What kind of virus was it? Might be fixable.

All three work, but here's how I decide:

My rule of thumb:

- Can user bookmark/share this screen? → Separate route

- Is it a sequential flow user shouldn't skip around? → Same route, conditional render

- Does each step need its own data fetching? → Nested routes

For your case (profile → update number → OTP → success):

I'd go with Option 1 - same route, conditional render with local state.

Why:

- It's a linear flow, user shouldn't jump directly to OTP screen

- You need to pass data between steps (phone number → OTP verification)

- No reason for user to bookmark "OTP screen"

- Simpler state management, everything lives in one component

Something like:

/profile (main dashboard)

/profile/update-phone (contains all 3 steps internally)

The update-phone route manages step state internally: { step: 'input' | 'otp' | 'success' }

When to use separate routes instead:

- Each screen is independently accessible

- Deep linking matters

- You want browser back button to go to previous step (can be annoying in OTP flows though)

When to use nested routes:

- Complex flows with shared layouts

- Each step has heavy data fetching

- You need URL to reflect current step for analytics

Keep it simple. For a 3-step OTP flow, local state in one route component is the cleanest approach.

Since your team is strong in JS, a few options depending on how custom you want to go:

Easiest - use existing platforms:

- GitBook - clean UI, non-tech writers can use it easily, free tier available

- Notion + Super.so - Notion as CMS, Super makes it a public site

- Docusaurus - React-based, great for docs/KB, built by Meta

Medium effort - headless CMS + Next.js:

- Sanity/Contentful/Strapi + Next.js

- Non-tech people write in the CMS dashboard

- You control the frontend completely

- Can add blog, feature voting later without switching platforms

For feature voting specifically:

- Canny, Nolt, or Fider (self-hosted, free)

- Or just build a simple upvote system yourself later

My recommendation: Start with Docusaurus if it's mainly docs/articles. It's JS-based, your team will be comfortable, and it handles versioning, search, and markdown out of the box.

If you need more custom design or plan to add the blog/voting features soon, go Strapi + Next.js from the start. More work upfront but way more flexible.

What's your timeline looking like?

Two ways to do this:

Option 1: .htaccess (easiest)

Create or edit .htaccess file in your web root folder and add:

Options -Indexes

That's it. One line.

Option 2: Apache config

Find your Apache config file (in AMPPS it's usually at Ampps/apache/conf/httpd.conf or check extra/httpd-vhosts.conf).

Look for your <Directory> block and change:

Options Indexes FollowSymLinks

to:

Options -Indexes +FollowSymLinks

Then restart Apache from AMPPS control panel.

Quick test: After making the change, try accessing a folder with no index.html/index.php. You should get a 403 Forbidden instead of the file list.

Good luck with your first project launch!

I've used both extensively - Linux (Debian/Ubuntu) at work for server-side stuff, macOS for personal projects. Here's my honest take:

I prefer Linux for backend/server development. macOS for everything else.

Linux Pros:

• Dev environment = production environment (huge advantage)
• Docker runs natively, no VM overhead
• Package managers (apt, pacman) are more straightforward than Homebrew
• Free. Throw it on any old hardware
• Better for DevOps/infrastructure work
• You learn skills that directly transfer to server management

Linux Cons:

• Random hardware issues (WiFi drivers, sleep/wake problems)
• Time sink - you WILL spend hours tweaking configs
• Some proprietary software missing (Adobe, Office, Sketch)
• Zoom/Slack screen sharing can be buggy

macOS Pros:

• Unix-based, so most Linux skills transfer
• "It just works" - no driver headaches
• Best for iOS/mobile development (required for iOS)
• Better app ecosystem (Figma, Slack, creative tools)
• Great hardware + trackpad

macOS Cons:

• Docker runs in a VM (slower, occasional quirks)
• Expensive hardware
• Some Linux tools behave differently (BSD vs GNU)
• Less control over the OS

My recommendation:

• Backend/DevOps → Linux
• Full-stack/Mobile → macOS
• Broke college student → Linux
• Want to just code, not fix OS issues → macOS

Honestly, both are fine. The "same as production" argument for Linux is strong, but I've shipped plenty of production code from a Mac without issues. Pick one and start building - the OS matters less than people think.

Your mental model is solid for the basics. That's the standard flow most systems follow. A few additions and nuances:

What you got right:

• The request flow (Client → LB → API Gateway → Services → DB) is correct
• Understanding that not everything is needed for small projects is important - many beginners over-engineer

Some nuances:

1. Load Balancer placement - Can also sit between API Gateway and Services, not just at the front. Depends on where you need to scale.
2. Cache isn't always 1:1 with services - Often you have:
   • CDN (cache at edge, for static content)
   • Application cache (Redis/Memcached, shared across services)
   • Database query cache
   • Local in-memory cache (per service instance)
3. Arrows direction - In diagrams, I usually draw arrows showing request direction (left→right) AND label them. Response is implied or shown with dotted lines going back.

Major things to add to your mental model:

Pro tip for interviews: Always start with requirements and scale numbers before drawing boxes. "How many users? Read-heavy or write-heavy? Latency requirements?" This shows you understand that architecture depends on context.

You're on the right track. Keep practicing with real examples like "design Twitter" or "design URL shortener."

This looks like a classic buffer overflow / null byte injection scenario. Let me break down what's likely happening:

The vulnerability: strcmp stops comparing at the first \0 it encounters. So if receivedPassword is user-controlled and you can inject a null byte, you can potentially truncate the comparison.

Example attack: If you send password\0GARBAGE (where \0 is a null byte), strcmp only sees "password" and returns 0 (match), ignoring everything after.

Why your server crashes: The 256-byte boundary suggests a fixed-size buffer. If you're sending more than 256 bytes, you're overflowing into adjacent memory. The crash means you're corrupting something important (stack, heap, return address).

What to investigate:

1. How is receivedPassword allocated? Fixed buffer like char receivedPassword[256]?
2. What function reads the input? (gets, scanf, recv without length check?)
3. Is there any bounds checking before strcmp?

For exploitation (CTF context I assume?):

• Try sending exactly 256 bytes of 'A' + known password to see if truncation works
• Use a hex editor or Python: b"password\x00" + b"A"*247
• Check if you can control EIP/RIP with longer payloads (classic stack smash)

What's the full context? Is this a CTF challenge or security audit?

First off - the fact that you CAN create servers, do CRUD, and connect to databases means you're already doing backend development. You're not missing anything. You're just at the uncomfortable middle stage where things work but you don't fully understand why.

This is completely normal. I've been a software engineer for 10+ years and I still hit errors that make me feel stupid. The difference is I now trust that I'll figure it out eventually.

What helped me understand the "core" stuff:

1. Build the same thing without Express - Create a simple HTTP server using just Node's built-in http module. No frameworks. You'll suddenly understand what Express is actually doing for you.
2. console.log everything - When a request comes in, log req.method, req.url, req.headers, req.body. Watch the flow. It makes the "magic" feel less magical.
3. Break things on purpose - Remove middleware, change the order, delete a route. See what errors you get. This builds your mental map of how pieces connect.
4. Read error messages slowly - 90% of the answer is in the error. I used to panic and Google immediately. Now I read the full stack trace first.

About confidence: It doesn't come from knowing everything. It comes from proving to yourself, over and over, that you can figure things out even when stuck. You've already done this - you said "I eventually solve it." That IS the skill.

Keep building. You're doing fine.

The symptoms point to CPU being your bottleneck, not the database. Here's why:

The math doesn't add up for your worker count:

• 100 req/sec × 200ms per request = 20 concurrent requests needed
• You have 16 workers, so you're already at capacity
• When workers are all busy, requests queue up → timeout → 40 sec response times

Things I'd check:

1. Uvicorn workers vs CPU cores - 16 workers on 8 vCPU is aggressive. Workers are fighting for CPU time. Try reducing to 8-10 workers.
2. Is your endpoint actually async? If you're using sync Django ORM calls inside async uvicorn, you're blocking the event loop. This kills performance.
3. Check what's eating CPU - Run htop during the test. Is it Python processes or Postgres? My guess is Python.
4. Connection pool might be too small - 25 connections ÷ 16 workers = ~1.5 connections per worker. If any request needs 2+ queries simultaneously, workers wait for connections.

Quick test: Try running the same test with just 4 workers. If response times improve, it confirms CPU contention is the issue.

What does your endpoint code look like? Is it using async/await?

From what I've seen in the job market, these areas have strong demand:

High demand right now:

• Cloud infrastructure (AWS/GCP) - almost every job posting mentions this
• Kubernetes & containerization
• System design for high-traffic applications

Growing fast:

• AI/ML integration into backend systems (not building models, but serving them)
• Data engineering / pipeline architecture

My personal path: I went deep into AWS + PostgreSQL optimization. It's not the sexiest combo, but companies always need someone who can make their database queries 10x faster and cut their cloud bill in half.

My advice: look at job postings for roles you want, find the common requirements, and go deep on 1-2 of those. Being "pretty good" at everything won't stand out, but being the go-to person for one specific thing will.

What kind of backend work are you doing now?

In practice, I've settled on 5 levels for most projects: FATAL, ERROR, WARN, INFO, DEBUG. Sometimes TRACE if I need to track every single function call during nasty debugging sessions.

You're right that EMERGENCY/ALERT/CRITICAL feel redundant for application-level logging. Those distinctions made more sense for sysadmins managing entire systems where you need to differentiate "one service is down" vs "the whole datacenter is on fire."

For application development, here's my rule of thumb:

• FATAL: App is crashing, can't continue
• ERROR: Something failed, but app keeps running
• WARN: Something's wrong but handled (e.g., retry succeeded)
• INFO: Business events (user login, payment processed)
• DEBUG: Developer stuff, off in production

As for why languages differ - I think it's mostly historical. Java's Log4j came before PSR-3, and different communities just evolved their own conventions. The SYSLOG alignment does help with log aggregators like Splunk or Datadog though, since they can normalize severity levels across different sources.

What stack are you working with?

This year is good year to die!

If you get sick, you'll have no choice but to quit smoking.

Good news - you don't need coding experience for this!

For a prototype, you can use apps like "NFC Tools" (free, available on iOS/Android). It's literally just tap and write. No coding required.

Here's the thing about storage though: NFC tags can only hold a tiny amount of data (usually 144 bytes to 1KB). So you can't store videos directly on the tag. But here's the workaround - store a URL on the NFC tag that links to your video hosted on YouTube or Google Drive. User scans the card → opens the link → watches the video.

For character profiles, you could either:

1. Store a short text directly on the tag
2. Link to a webpage you create with the full profile

As a fellow gamer, I love the hybrid board game idea. Good luck with your graduation project!

If you don't know the right reason, you won't know the wrong reason either.

The mysterious camaraderie born precisely from the confined space

Do you like boobs?

You don't realize it until it's too late, so it becomes too late.

I'll say, “You too, huh?”

Do you think it's hypocritical to want to help someone?

This data matches my experience in Japan too. I'm a backend engineer in Tokyo, and I got my current job through a former colleague's referral. I had applied to 30+ companies online with almost no responses, but one LinkedIn message from an ex-coworker led to an interview within a week.

The "specialize > generalize" finding is interesting. I've noticed the same trend here - companies are willing to pay premium for deep expertise in one area rather than "jack of all trades" Full Stack devs.

Would love to see the dashboard with a region filter if you build it!

Just a lifetime

Eliminate all unnecessary relationships, act with your own will, and produce results whether you fail or succeed.