Ruby Seminar Osaka (June 2025) Report

I attended an event called "Ruby Seminar Osaka (June 2025)" on June 27th.

https://www.ruby.or.jp/ja/news/20250311

https://posfie.com/@tmtms/p/Q6Glw82

It was the day before Kansai RubyKaigi 2025, so I went along as well... or rather, the Ruby Seminar was more of the main event for me, and Kansai RubyKaigi felt more like a bonus.

My goal was Mr. Seki's talk on Ninja-style Testing. I think the first time I heard about Ninja-style Testing was probably at DevSumi in 2008. I thought it was amazing back then, and hearing it again now, it's still incredible.
I wonder if Ninja-style Testing is reproducible outside of Mr. Seki's team.

The following are some rough notes I took. I thought about writing them properly, but it doesn't look like I will, so I'm publishing them as notes.

---

"Reverse Alpha Syndrome and AI Coding" by Matz

• Alpha Syndrome
• A pet dog believing it is the leader
• Reverse Alpha Syndrome
• Introducing new technology -> Humans becoming subordinates to that technology
• People becoming subordinates of their own accord
• A concept conceived by Matz
• "Chore work for AI" increases
• The parts that were fun for humans are lost
• Some people give up on coding because of AI
• Working for the AI
• Negotiation, sales, analysis, quality assurance, etc.
• Humans must not be excluded
• Retronym
• Word meanings change due to new concepts
• Coding -> Human coding
• Natural coding?
• robo dev is quite good
• Crashes occasionally
• 20M tokens/day
• In terms of coding ability, Gemini is smarter
• Reminiscent of pair programming
• Easy because it can be done asynchronously
• Trying out new ways of doing things is fun
• Might get bored of it eventually
• It's getting smarter and smarter
• How will future learners acquire knowledge?
• Effective for initial learning
• Doesn't get angry no matter how many times you ask
• A good teacher
• How to utilize AI from the intermediate level onwards
• How to learn knowledge and experience
• How humans will interact when AI becomes even smarter
• Photography and painting -> Both survived
• Horse-drawn carriages and cars -> Disappeared
• Which one is programming?

"XP and Testing: 25 Years of Practice with Ninja-style Testing" by Mr. Seki & Ms. Miwa

https://speakerdeck.com/m_seki/xp-testing-and-ninja-testing

• XP
• Post-software engineering
• Extreme
• People make mistakes
• Make mistakes apparent as early as possible
• Ninja-style Testing
• A very good version of iterative development
• Actually, it's just XP
• XP has an internal mechanism to push extremes even further
• A successful test -> A test that found a new problem
• A failed test -> A test that didn't find any problems
• Testing is essentially manual testing
• Automated testing
• Even if it turns green 1,000 times, the code doesn't improve by a single bit
• The value lies in the refinement of the implementation during the process of automation
• Ninja-style Testing
• Testing to find unknown problems
• Manual
• Testing effective for iterative development
• It's difficult to find problems with planning, specifications, and design during those specific phases
• Large-scale development separates the creation phase and the confirmation phase
• Even if you think of better specifications or design during the confirmation phase, you can't respond to them
• Iterative development
• Break down large requirements into small units of a few days for development
• Must perform frequent system tests
• Confirming that everything implemented so far works without issues
• That's where Ninja-style Testing comes in
• A practice of performing TDD at the level of acceptance testing
• Development starting from acceptance tests
• Realizing stories guided by acceptance tests
• Every time a story is created, conduct acceptance tests for all stories
• Think starting from "how to test"
• Use testing as a starting point to think about and keep questioning the entire development
• Stories are managed with tickets
• Read through them with everyone every morning
• Treat bugs found during development the same as stories
• The ticket management system is home-made using Ruby
• Wants to package it and make a fortune
• Cases where Agile doesn't work well
• Because it's just repeating the bottom of the V-model
• Developers and testers are separated
• Just divided the area close to programming into iterations
• Ninja-style
• Perform all steps of the V-model in every iteration
• Everyone is a developer
• All steps are performed by programmers and testers who handle non-programming phases
• Want to see the results in short cycles -> Acceptance tests per iteration
• Want to tune specifications and design in short cycles
• Want to polish the product until the very last minute
• Don't postpone the difficulty of system integration
• Integrate with the system even for small changes
• Do it even if it's hard; do it because it's hard
• Postponing it tends to lead to "stagnant development"
• Don't postpone bug fixes
• If a bug is found, stop development until the cause is understood
• Don't judge the severity by surface-level symptoms alone
• A bug is just a visible part of a problem, so look for the real underlying issue
• Postponing fixes slows down the pace of development
• If you don't solve current problems, you can't find more sophisticated ones
• Face the scale
• Initially, want to verify all cases in one day
• -> Instead of one day, run everything within a certain period
• Prioritize test cases for new stories and recently fixed tickets
• Algorithm
• Everyone tests
• Today's recommended tests
• Only recommend an amount that seems doable in a day
• Became able to fix seemingly difficult problems without hesitation
• A sense of security that if something happens, it can be found and fixed
• Actively look for discrepancies from the ideal
• Everyone develops while asking what makes a good product
• Similar changes occurred in people who joined later
• Timebox hypothesis
• Easier to think when there's a set period
• One hour, one day, one week
• Remaining documentation
• Read them when you've forgotten
• Usage
• Happy when the expected behavior of the product at that time is documented
• Tickets aren't orders or receipts
• Helpful for newcomers
• Together with seniors
• Product specifications, behavior, etc.
• Repeating this is what works

"Rails Application and Performance Tuning — A Case Study Supporting 50,000 Requests Per Second for a Mobile Ordering System —" by Mr. Okumoto

https://speakerdeck.com/falcon8823/railsapurikesiyonto-pahuomansutiyuningu-miao-jian-5mo-rikuesutono-mobairuodasisutemuwozhi-erushi-li-rubysemina-da-ban

• Rails applications and performance
• kaigionrails.org/2024/talks/falcon8823
• Built and delivered an app as a middle schooler to earn tuition for a technical college
• Design and mindset with performance in mind
• API-based Rails
• Building on the basics
• Avoiding N+1 queries and slow queries
• Computational complexity and fast algorithms
• Not everything can be solved on the application server
• Web development is a mixed martial arts of architecture
• Being mindful of it from the initial design stage
• Query and table design that prevents N+1
• Path and controller design
• Caching strategy
• CDN/Application cache
• N+1
• Latency increase due to DB communication costs
• Run Bullet gem in CI as well
• Caching with a CDN is a magic bullet
• It's difficult to implement later
• Consider caching for APIs that don't depend on individual user data
• Effectively reduces load on Rails servers
• Be careful of information leaks via caching
• Understand Cache-Control / Vary / ETag headers well
• Understand the behavior of each provider
• Separate paths and controllers that are to be CDN cached
• Configure CDN to not cache api/private/*
• Operate with simple rules that make it easy to set up guardrails
• It gets complicated when you start thinking seriously about CDN caching
• Recommended to use stale-while-revalidate as a workaround
• Returns stale cache until revalidation even after expiration
• Prevents frequent cache misses even with short settings
• Responding to CORS at the CDN level
• Cases where preflight requests occur
• It's wasteful for Rails to respond to even minor requests
• Consider CDN caching or responses
• Effectively making users wait
• Design so as not to ruin the user experience
• Server errors lead to users making inquiries
• "Currently busy. Please try again after a short while" — communicates to the user what they should do
• Educating users and clients is also important
• Load testing
• Scenario testing
• Simulating requests based on user usage scenarios
• Actual behavior in the browser
• HAR files
• There are tools that can reproduce items saved from the Chrome network tab
• Measurement
• Aggregating response times per path as a minimum
• Better to have an APM
• Use mocks to avoid putting load on external APIs
• Testing with HTTPS disabled
• The performance of the load generator side is insufficient otherwise
• Be careful with Load Balancer pre-warming
• Check the overall error rate
• Error rate per endpoint
• Tuning
• Cost and business impact
• Avoiding service downtime
• User experience
• Infrastructure costs
• Reducing engineer man-hours
• Tuning in order: App/DB/Web/LB/CDN
• When it's slow, it's usually your own fault
• Start with endpoints where response time is slower than average
• Could be 100x faster > 1000ms
• Endpoints with high (number of requests x latency)
• 2-10x performance improvements
• Analyze PostgreSQL execution plans using GPT
• Parameter tuning
• Depends on the nature of the application, so no general rule
• The goal is to maximize the utilization of computing resources
• Tweak this last
• "Performance Tuning for Deployment" in Rails Guides
• Don't lose sight of the goal setting
• Start from where you can make broad, effective changes
• Experience design involving users and clients