My 86-Hour Web Engineering Roadmap

86 total hours of focused study—80 hours of raw coding and 6 hours of environment wrestling—is all it took to move from zero to deploying functional web systems. I'm currently working as a truck driver in Japan, but I've spent the last 24 days leveraging my logistics background to pivot into web engineering. Instead of just reading theory, I've focused on a "build-first" approach, moving through Python automation and Ruby on Rails to real-world deployments.

The Learning Breakdown

I structured my progress into five distinct stages to ensure I wasn't just copying tutorials, but actually solving problems.

Stage 1-3: Python & Automation (52 hours)
I started with Python fundamentals and immediately jumped into scraping. The goal was to automate data collection, which led to two specific projects:

• Puoppo Auto-Analysis: A system built on Lubuntu that retrieves poll data and runs AI-powered text analysis.
• Bakery Sales Aggregator: This combined web scraping with Excel automation to handle sales data aggregation, which is a practical use case for any small business.

Stage 4: Ruby on Rails (23 hours)
I shifted to the MVC architecture to understand how professional web apps are structured. I spent a significant amount of time on rails_practice, focusing specifically on configuration management and Git rebasing to keep my version control clean.

Stage 5: Real-World Integration (5 hours)
My most recent project, the hiroshima-logistics-hub, aggregates real-time weather and traffic for the Hiroshima region. This is where I hit my first major deployment wall.

Solving Render Free Tier Memory Crashes

When deploying to Render's free tier (which caps at 512MB RAM), my Rails build kept crashing during the asset compilation phase. The memory overhead of the build process was simply too high for the instance.

To fix this, I stopped relying on the platform's build pipeline and moved to a local precompilation strategy. Here is the logic I used to ensure the app stayed alive:

1. Local Asset Precompilation: I ran the assets precompile command on my local machine instead of letting the server do it.
2. Writable SQLite Config: Since Render's filesystem is ephemeral, I had to explicitly configure the SQLite3 database storage to reside in a writable directory to prevent "Read-only file system" errors.

Example of the directory structure adjustment for the database config in database.yml:

production:
  adapter: sqlite3
  database: storage/production.sqlite3
  pool: 5
  timeout: 5000

Engineering Under Constraints

Working with limited hardware and time has forced me to adopt a specific AI workflow and development mindset:

• The "Plan C" Strategy: When I hit a memory cap or a library conflict, I don't just search for a "fix." I look for a way to bypass the requirement entirely. If a heavy library is causing a crash, I look for a lightweight alternative or a way to handle the logic via a simpler script.
• Hardware Validation: I don't trust desktop browsers. I verify every deployment on a physical device (I use a Xiaomi 15T) to ensure the UX actually works in a mobile environment, which is where most logistics-related tools are actually used.
• Sustainable Output: I've learned that coding while mentally exhausted leads to bugs that take three times longer to fix. I now treat scheduled rest as a technical requirement of the project, not a luxury.

For anyone starting from scratch, the fastest way to learn is to find a problem in your current professional domain—like logistics—and build a tool to solve it. It turns the learning process into a practical tutorial for your own life.

My progress and full source code are available here:
https://github.com/tosane932