DEV Community: tosane932

🏎️ Mini 4WD Lane Change Tuning and Python Debugging Follow the Same Problem-Solving Process

tosane932 — Sat, 25 Jul 2026 22:23:36 +0000

Introduction

Hello from Japan! 🇯🇵

I am a professional truck driver teaching myself Python while working toward a career transition into web engineering.

Without relying on traditional textbooks, I developed two Flask applications through conversations with AI:

This article is based on my experience after approximately one and a half months and 98 hours of programming study as of June 25, 2026.

In this article, I compare two seemingly unrelated activities:

Tuning a Mini 4WD racing car to handle a lane change section in 2021
Debugging Python applications today

I realized that both activities follow almost exactly the same problem-solving process.

What Is a Mini 4WD Lane Change?

Mini 4WD cars are small, motor-powered racing cars originally created by the Japanese model manufacturer Tamiya.

They run automatically around plastic racing tracks without steering controls.

A lane change, often abbreviated as LC in the Japanese Mini 4WD community, is one of the most difficult sections of a track.

A high-speed car must climb a steep section while moving from one lane to another.

Many beginners experience a course out, abbreviated as CO, at this section—the car leaves the track instead of completing the lane change.

Analyzing the Course-Out Failure: The Same Structure as Root Cause Analysis

The position of the car when it first hits the track wall.

The position of the car when it hits the next wall.

This is the critical point. Once the car reaches this position, it loses resistance from the track wall and continues moving forward while lifted off the track.

The rear rollers also lose contact with the wall, leaving the car airborne without anything guiding it back toward the track.

Once the car reaches this position, recovery is almost impossible.

After analyzing the car's movement, I discovered that the course out did not have a single cause.

Several events occurred in sequence:

The front of the car lifted
The stabilizer failed to make contact with the track wall
The roller moved beyond the edge of the wall
The car lost resistance and continued moving straight ahead

Behind one visible failure was a chain of multiple causes.

This is similar to debugging a Python error.

Fixing only the line mentioned in an error message does not always solve the real problem.

You must trace the stack trace backward and identify:

Where the failure started
What happened before the visible error
Which conditions allowed the failure to occur
Whether several causes interacted with each other

The course out was only the final symptom.

The real problem began several steps earlier.

Implementing a Solution: Subtraction Is as Important as Addition

Defining the mechanical problem.

One of the modified sections.

Another modified section.

Once the cause has been identified, the next step is to implement a solution.

However, an important lesson from Mini 4WD tuning is this:

Simply adding more parts does not necessarily prevent a course out.

Adding parts increases the car's weight.

Additional weight may change the car's balance.

Fixing the left side may cause the right side to lift.

To keep the entire car stable, you must manage both addition and subtraction.

The same problem can appear in Python code.

# ❌ Addition-only debugging:
# parameters and obsolete processing keep accumulating

def get_sales(
    date,
    store,
    category,
    flag=True,
    debug=False,
    retry=3
):
    if debug:
        print("debug mode")

    if flag:
        old_result = _legacy_calc(date)  # Obsolete logic remains

    # Main processing continues...

Whenever a new problem appears, it may be tempting to add:

Another parameter
Another flag
Another conditional branch
Another exception handler
Another temporary workaround

This may fix the immediate symptom, but it also makes the code heavier and more difficult to understand.

A better solution is sometimes subtractive debugging, which is closely related to refactoring.

Remove obsolete arguments, delete unused logic, and simplify the structure.

In Python, techniques such as early returns can also reduce unnecessary nesting.

# ✅ After subtraction:
# unnecessary parameters and obsolete logic have been removed

def get_sales(date, store, category):
    # Only the required processing remains
    # Main processing continues...

This follows the same principle as tuning a Mini 4WD car.

If you only continue adding parts, the car becomes heavier and may develop new balance problems.

If you only continue adding conditions to code, the program accumulates technical debt and may develop new bugs.

A system becomes stable only after unnecessary elements are removed and the overall structure is reorganized.

From “It Cleared Once” to “It Clears Reliably”

The car's posture improved slightly.

The final modified section.

Clearing the lane change once is not the same as clearing it reliably every time.

With Mini 4WD tuning, my goal was to create a setup that remained stable across repeated test runs.

The same idea applies to Python development.

My goal is not simply to write code that works once.

I want to build code that continues to operate reliably in a production environment.

The structure of the challenge is the same:

Reproduce the failure
Observe the behavior
Identify the chain of causes
Apply a focused change
Test repeatedly
Confirm that the result is stable

A single successful run is not enough evidence of reliability.

Summary

Mini 4WD Lane Change Tuning	Python Debugging
Observe the course-out behavior	Observe the error
Identify the chain of causes	Trace the stack trace
Balance addition and subtraction	Remove unnecessary arguments and processing
Perform repeated test runs	Run repeated tests
Achieve stable laps	Achieve stable production operation

The tools and environments may be completely different, but the underlying problem-solving process remains the same.

Whether I am tuning a Mini 4WD car or debugging a Python application, the essential steps are:

Observe facts carefully
Avoid assuming that the visible symptom is the root cause
Break the problem into smaller parts
Change one relevant factor at a time
Remove unnecessary complexity
Verify stability through repeated testing

Problem-solving skills can transfer across fields.

An experience gained from a physical hobby can later become a useful way of thinking about software development.

You can find videos of the Mini 4WD car running and more detailed tuning records on Instagram:

Instagram: @miacis93

You can also find my development projects on GitHub:

GitHub: tosane932

"Take the Well-Maintained Road Over Risky Shortcuts": Ditching Web Scraping for an AI App Powered by Official RSS & Gemini (Lessons from Logistics)

tosane932 — Sat, 25 Jul 2026 20:11:43 +0000

Design Philosophy and Practical Solutions of "Puoppo," an Automated AI Trend Analysis System Built with RSS × Gemini 2.5 Flash

GitHub Repository: tosane932 / puoppo_app

1. Introduction

An active truck driver in Japan self-studying Python, leveraging logistics domain knowledge to transition into a Web Engineer.

In this article, I share the design philosophy and technical choices behind "Puoppo," an automated AI trend analysis system I built during my 42nd hour of studying Python (with no IT background or prior development experience).

Rather than a gimmick chasing short-lived trends, the system is built on a timeless design philosophy—like a reliable pair of jeans that never wears out—focused on "reliably controlling domain data from the field."

2. Problem Definition and System Overview

Background & Problem

In daily technical trend and news gathering, visiting multiple sources and digesting noisy, long articles became a major bottleneck. I needed a mechanism to consume high-density primary information within a limited timeframe each morning (e.g., the few minutes it takes to cook a Japanese omelet).

The Solution

Simply enter topics you want to know about (e.g., politics, inflation, latest music news) into a text box, and the AI actively collects and structures up to 100 related articles. You can digest everything in a single screen pane just by scrolling.

Key Specifications

Performance: Executes the entire pipeline from keyword input to collection and summarization in approximately 10–15 seconds.
UI/UX: A simple 1-column UI connecting search to results in a straight line, eliminating user confusion.

Tech Stack

Language / Framework: Python 3 / Flask
Core Logic: RSS Feed Parsing (Dynamic Endpoint Control)
LLM Integration: Gemini API (gemini-2.5-flash)
Frontend: HTML / Jinja2 / JavaScript (No FW)
Environment: Ubuntu (Lubuntu) / VS Code / .venv

3. Demo

The actual running environment and UI design are available in the demo video below (YouTube: 7m 49s).

(Click the image to watch on YouTube)

4. Technical Choices & Trade-offs from a Field Perspective

① The Limits of Scraping & Adopting RSS as "Safe Endpoints"

Initial designs tested direct web scraping from major news sites, but IP blocking and maintenance costs due to layout changes presented major hurdles.

Instead of trying to technically "bypass" blocks, I pivoted to leveraging official RSS feeds provided by publisher media.
This decision stems from practical logistics experience: "Taking a well-maintained, reliable road yields better overall efficiency (speed) than forcing a shortcut." This allowed the immediate setup of a safe and dependable data pipeline.

② Choosing Flask for a 10-Hour Build

The core value of this system is instantaneous data flow: aggregating data from dynamic keywords, passing it to an LLM, and returning results.
Since authentication and ORM were unnecessary for this phase, I chose Flask, a micro-framework that enables rapid routing setup. By stripping away over-engineering, I rolled out the prototype in just one day (~10 hours).

③ Cost & Speed Optimization via Gemini 2.5 Flash

Injecting context from up to 100 article texts in a single request required an LLM model with a vast token capacity, making Gemini an obvious choice.
Furthermore, balancing rapid response times (10–15 seconds) with excellent cost-effectiveness for personal projects led to selecting gemini-2.5-flash, a lightweight model selected as of May 2026.

④ Stripping Away Design & Focusing on a 1-Column UI

Rather than building component architectures using modern JavaScript frameworks (React/Vue), I implemented it with plain HTML/CSS.
By eliminating resource expenditure on complex UI layouts, I prioritized pure utility: "allowing users to absorb accurate information smoothly into their minds without stopping their scroll."

5. 🚀 Setup Instructions (Mac / Linux)

Steps to run locally in a virtual environment (Linux / macOS):

# 1. Clone the repository
git clone [https://github.com/tosane932/puoppo_app.git](https://github.com/tosane932/puoppo_app.git)
cd puoppo_app

# 2. Create and activate virtual environment
python3 -m venv .venv
source .venv/bin/activate

# 3. Install required packages
pip install -r requirements.txt

# 4. Set API Key
export GEMINI_API_KEY="YOUR_API_KEY"

# 5. Run the app
python app.py

6. 🚀 Setup Instructions (Windows)

Steps to run locally on Windows:

# 1. Clone the repository
git clone [https://github.com/tosane932/puoppo_app.git](https://github.com/tosane932/puoppo_app.git)
cd puoppo_app

# 2. Create and activate virtual environment
python -m venv .venv
# [For PowerShell]
.venv\Scripts\Activate.ps1
# [For Command Prompt]
.venv\Scripts\activate.bat

# 3. Install required packages
pip install -r requirements.txt

# 4. Set API Key
# [For PowerShell]
$env:GEMINI_API_KEY="YOUR_API_KEY"
# [For Command Prompt]
set GEMINI_API_KEY=YOUR_API_KEY

# 5. Run the app
python app.py

7. Future Roadmap (Deepening Skills & Proving Capabilities)

While current capabilities satisfy initial requirements and deliver reliable results, I plan a two-stage refactoring process by the end of 2026 to elevate the system into production-ready quality:

① Decoupling Tightly Coupled Architecture

I will organize and decouple the logic currently centralized in Flask (RSS parsing, LLM control, view control), transitioning toward a decoupled layered architecture inspired by Clean Architecture.

② Building Automated Testing Infrastructure

To adapt to changes in external APIs (Gemini) or RSS feed formats, I will introduce unit tests and mock tests using Pytest, creating a robust codebase oriented around Continuous Integration (CI).

8. Conclusion

Through the development of "Puoppo," I reconfirmed the power of minimalism: "simply combining only the necessary components to solve the specific problem in front of you," without getting swayed by over-engineering or trending tech stacks.

Reducing wasted time spent searching for news, and using created resources to decide what to build next—this system reminds me of the true joy of engineering.

GitHub Repository: tosane932 / puoppo_app

https://qiita.com/tosane932/items/974e12e369eda378549b

Refactoring My Learning Logs: Why I Rewrote Emotional Notes into Fact-Based Technical Reports

tosane932 — Sat, 25 Jul 2026 14:33:57 +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 journey with developers worldwide!)

As of June 18 (Day 38 / 93 total study hours), I completed a full refactoring of my past three articles and GitHub documentation, restructuring them into a strictly fact-based technical format. Here is the rationale and process behind this effort.

Check out my GitHub here👈️

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

2. Purpose of the Refactoring

Upon reviewing my previously published articles and repository documentation, I realized that subjective and emotional descriptions written at the time often overshadowed technical facts and decision-making logic.

To share clear, actionable, and accurate engineering insights, I restructured the information based on the following principles:

Eliminating Subjective Language: Removed metaphors and emotional adjectives such as "passionate," "tough," or "gritty."
Structuring Facts: Documented exact time spent, specific technical constraints encountered, and the logical steps taken to overcome them.
Ensuring Consistency: Re-aligned all dates, study days, and progress metrics across my records for accuracy.

3. What Was Refactored

During this documentation refactoring, I executed two main tasks:

Updated 3 Past Articles: Corrected timelines, shifted to a technical report structure, and re-framed project outcomes into objective descriptions.
Cleaned Up GitHub Repositories: Updated project documentation (such as README files across repositories) to ensure all information is grounded in technical facts.

4. The Philosophy of "Documentation Refactoring"

Just as we refactor code to reduce technical debt, I realized that written technical outputs (learning logs) are maintainable "assets" that require ongoing care.

Eliminating Documentation Debt: Articles written under emotional influence lose clarity over time and create unnecessary noise for readers. Extracting pure facts increases information density and value.
Maintaining Objectivity: Treating my past self as a "code review target" allows me to objectively verify whether my technical decisions were sound, thereby sharpening my learning accuracy.

5. Conclusion

Moving forward, I will maintain a fact-based framework for all future learning outputs while routinely refactoring my documentation.

By consistently building a repository of accurate, structured information, I aim to improve both my own learning efficiency and the long-term value of my documented work.

Follow my latest progress and check out my repositories here:

👉 https://github.com/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

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

DEV Community: tosane932

🏎️ Mini 4WD Lane Change Tuning and Python Debugging Follow the Same Problem-Solving Process

Introduction

What Is a Mini 4WD Lane Change?

Analyzing the Course-Out Failure: The Same Structure as Root Cause Analysis

Implementing a Solution: Subtraction Is as Important as Addition

From “It Cleared Once” to “It Clears Reliably”

Summary

"Take the Well-Maintained Road Over Risky Shortcuts": Ditching Web Scraping for an AI App Powered by Official RSS & Gemini (Lessons from Logistics)

Design Philosophy and Practical Solutions of "Puoppo," an Automated AI Trend Analysis System Built with RSS × Gemini 2.5 Flash

1. Introduction

2. Problem Definition and System Overview

Background & Problem

The Solution

Key Specifications

Tech Stack

3. Demo

4. Technical Choices & Trade-offs from a Field Perspective

① The Limits of Scraping & Adopting RSS as "Safe Endpoints"

② Choosing Flask for a 10-Hour Build

③ Cost & Speed Optimization via Gemini 2.5 Flash

④ Stripping Away Design & Focusing on a 1-Column UI

5. 🚀 Setup Instructions (Mac / Linux)

6. 🚀 Setup Instructions (Windows)

7. Future Roadmap (Deepening Skills & Proving Capabilities)

① Decoupling Tightly Coupled Architecture

② Building Automated Testing Infrastructure

8. Conclusion

Related Articles

Refactoring My Learning Logs: Why I Rewrote Emotional Notes into Fact-Based Technical Reports

1. Introduction

2. Purpose of the Refactoring

3. What Was Refactored

4. The Philosophy of "Documentation Refactoring"

5. Conclusion

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

1. Introduction

2. The 86-Hour Learning Roadmap

Stages 1–3: Automation & Scraping Projects

Stage 4: Practical Ruby on Rails

Stage 5: Real-World System Integration

3. Key Takeaways for Resource-Constrained Development

4. Future Outlook

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

1. Introduction

2. Environment

3. Challenges & Solutions

① Git Repository Structure Inconsistency

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

③ SQLite3 Write Permission Error

4. Conclusion

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

Introduction

1. Initial Concept: Considering In-Vehicle Local Infrastructure

2. Challenges Leading to the Pivot

① Hardware Maintenance Risks

② Divergence from Learning Goals

③ Insufficient Market Need Analysis

3. Future Roadmap