DEV Community: tosane932

24 Days of Coding: An 86-Hour Roadmap from Truck Driver to Web Engineer

tosane932 — Fri, 24 Jul 2026 23:48:43 +0000

1. Introduction

Hello from Japan! 🇯🇵

I am an active truck driver in Japan self-studying Python and Web technologies, leveraging my logistics domain knowledge to transition into a Web Engineer.

(English is my second language, but I'm excited to share my progress with developers worldwide!)

I started my learning journey on May 12, 2026. As of June 4, I have logged 24 days and 86 cumulative hours of study. This article documents my progress, learning roadmap, and project milestones chronologically.

Check out my GitHub here👈️

(Note: Most repository documentation and commit messages are currently in Japanese.)

2. The 86-Hour Learning Roadmap

A quick breakdown of my 86 hours: 80 hours were dedicated to hands-on development and implementation, and 6 hours were spent on environment configuration, documentation, and workflow optimization.

Stages 1–3: Automation & Scraping Projects

① Fundamentals & Web Scraping (25 hours) Learned core Python syntax and built automated scripts to collect targeted web data.
② Puoppo Auto-Analysis System (15 hours) Implemented automated poll data retrieval and AI-powered text analysis on Lubuntu.
③ Bakery Sales Aggregation System (12 hours) Integrated web scraping with automated Excel processing to streamline sales data aggregation.

Stage 4: Practical Ruby on Rails

④ rails_practice (23 hours) Explored MVC architecture in Ruby on Rails. Practiced configuration management and Git rebasing to build a solid foundation in web framework operations.

Stage 5: Real-World System Integration

⑤ hiroshima-logistics-hub (5 hours) Built a web system to aggregate real-time weather and traffic conditions in the Hiroshima area.
- Technical Fix: To bypass build crashes on Render (Free Tier / 512MB RAM), I precompiled assets locally and configured SQLite3 database storage in writable directories before deployment.

3. Key Takeaways for Resource-Constrained Development

Through these projects, I established three operational principles for developing efficiently within tight constraints:

Maintaining a Sustainable Pace: Physical and mental fatigue directly reduce output quality. Scheduling intentional rest is a core part of my development workflow.
Problem-Solving Under Constraints: Instead of seeing hardware specs or memory caps as brick walls, I treat them as "engineering puzzles." I always brainstorm alternative strategies (Plan C), such as tweaking configurations or reducing reliance on heavy libraries.
Real-Device Verification: Beyond desktop browser checks, I routinely test applications on mobile devices (Xiaomi 15T) to verify UX consistency in real-world scenarios.

4. Future Outlook

It has been 24 days since I wrote my first line of code. Moving forward, I will focus on building production-ready Web applications to build a solid portfolio that proves my practical engineering capabilities.

Follow my journey and check out my repositories here:

👉 https://github.com/tosane932

Deploying Rails 8 on Render Free Tier: Bypassing the 512MB RAM and Read-Only Storage Limits

tosane932 — Fri, 24 Jul 2026 20:55:43 +0000

1. Introduction

Hello from Japan! 🇯🇵

I am an active truck driver in Japan self-studying Python, leveraging my logistics domain knowledge to become a Web Engineer.

(English is my second language, but I'm excited to share my journey with developers around the world!)

I started my self-study journey on May 12, 2026. In this article, I summarize the process of deploying Ruby on Rails 8 to a PaaS (Render Free Tier) and how I tackled the strict resource constraints I ran into.

Check out my GitHub here👈️

(Note: Most repository documentation and commits are currently in Japanese.)

2. Environment

Development: Lenovo G580 (Lubuntu 24.04 LTS / 16GB RAM / Upgraded SSD)
Production: Render (Free Tier: 512MB RAM)
Testing Device: Xiaomi 15T

3. Challenges & Solutions

① Git Repository Structure Inconsistency

Issue: An unnecessary .git directory existed inside a subdirectory, causing errors during deployment.
Solution: Deleted the nested .git directory to restore repository hierarchy integrity.

② Build Failure via Render Free Tier RAM Limit (512MB)

Issue: Executing asset compilation on Render triggered Out-Of-Memory (OOM) crashes, forcibly killing the build process.
Solution: Precompiled assets locally and committed the static files to the repository, significantly reducing memory usage on the production build server.

③ SQLite3 Write Permission Error

Issue: Encountered database write permission errors during CRUD operations in production. Render's file system is read-only by default, except for designated directories (such as storage/).
Solution: Updated config/database.yml to direct the SQLite3 database file to a path with write permissions (e.g., under storage/).

4. Conclusion

By applying these workarounds, I successfully verified the deployment and operation of a Rails 8 application on Render's Free Tier.

(Please note: Although production runtime works properly, because the setup prioritizes local configurations, some automated CI tests on GitHub currently report errors.)

For full source code and details, feel free to visit my repository:

👉 https://github.com/tosane932/rails_practice

Why I Dropped the In-Vehicle Local Server Concept and Pivoted to Web Application Development.

tosane932 — Fri, 24 Jul 2026 15:58:32 +0000

Introduction

This is a record at 20 days into my learning journey (81 cumulative hours), starting May 12, 2026. (As of late May)

In this article, I summarize the background and decision-making criteria for halting my initially planned "In-Vehicle Local Server Operations Management System" and pivoting toward Web development.

Check out my GitHub here👈️
(🇯🇵Note: Most repository documentation and commits are currently in Japanese.🏯)

1. Initial Concept: Considering In-Vehicle Local Infrastructure

For independent transport operators, I considered using an affordable secondhand PC (running Lubuntu) as an in-vehicle server to store and manage daily reports and operational data offline.

Goal: Build a low-cost operations management infrastructure while eliminating monthly telecommunication subscription fees.
Tech Stack / Architecture: Power inverter, local network setup using a Lubuntu PC, and automated Excel generation for daily logs.

2. Challenges Leading to the Pivot

As I progressed with the design, I determined that continuing was infeasible due to the following technical and operational challenges:

① Hardware Maintenance Risks

If running multiple secondhand PCs, it would be difficult for an individual to permanently cover failure risks caused by aging hardware, making it tough to guarantee infrastructure reliability.

② Divergence from Learning Goals

This project primarily revolved around Linux infrastructure setup and network configuration. I judged that this had little direct relevance to my primary goal: acquiring skills in "Web Application Development (Python/Flask, Ruby on Rails)".

③ Insufficient Market Need Analysis

The system architecture was tailored solely to a specific operational environment, failing to adequately account for broader market needs or the operational complexities of other logistics businesses.

3. Future Roadmap

Removing emotional attachment, I prioritize the shortest path toward achieving my primary goal.

Mastering Deployment with Flask: Experience the Web app publishing process and understand fundamental architecture.
Transitioning to Ruby on Rails: Learn a high-demand Web framework used in production to begin building my portfolio.

Going forward, I will focus on building a track record through Web development projects. My daily learning progress and development history are available on GitHub below:

👉 https://github.com/tosane932