Attending Ruby Seminar Osaka (June 2025)

On June 27th, an event called "Ruby Seminar Osaka (June 2025)" was held, and I went there.

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 there while I was at it... or rather, the Ruby Seminar was the main focus for me, and Kansai RubyKaigi was more of a bonus.

My goal was to hear Seki-san talk about Ninja-style Testing. I think the first time I heard about Ninja-style Testing was probably at Developers Summit 2008; I thought it was amazing then, but hearing it again now, it's still incredible.
I wonder if Ninja-style Testing is reproducible by teams other than Seki-san's.

Okumoto-san's talk was also great.

Below are the rough notes I took. I thought about writing them properly, but since I probably won't, I'm publishing them as notes.

---

"Reverse Alpha Syndrome and AI Coding" by Matz

• Alpha syndrome
• A pet dog thinking it's the leader
• Reverse alpha syndrome
• Introducing new technology -> humans becoming subordinates to the new technology
• People voluntarily becoming subordinates
• A concept conceived by Matz
• "Chores for AI" increase
• The fun parts for humans are lost
• Some people give up on coding because of AI
• Working for AI
• Negotiation, sales, analysis, quality assurance, etc.
• Humans must not be excluded
• Retronym
• The meaning of words changes due to new concepts
• Coding -> Human coding
• Natural coding?
• robo dev is quite good
• Sometimes it crashes
• 20M tokens/day
• In terms of coding ability, Gemini is smarter
• Reminiscent of pair programming
• Easy because it can be done asynchronously
• It's fun to try new ways
• I might get bored of it eventually
• It's getting smarter and smarter
• How will newcomers gain knowledge?
• Effective for initial learning
• Doesn't get angry no matter how many times you ask
• A good teacher
• How to utilize AI after the intermediate level
• How to learn knowledge and experience
• How humans will be involved when AI gets even smarter
• Photography and painting -> survived
• Horse carriages and automobiles -> disappeared
• Which one is programming?

"XP and Testing: 25 Years of Practice in Ninja-style Testing" by Seki-san & Miwa-san

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

• XP
• Post-software engineering
• Extreme
• Humans make mistakes
• Make it so mistakes are caught early
• Ninja-style Testing
• A very good version of iterative development
• Actually just XP
• XP has an inherent mechanism to push extremeness even further
• Successful test -> A test that found a new problem
• Failed test -> A test that didn't find any problems
• Testing is fundamentally manual testing
• Automated testing
• Even if it turns green 1,000 times, it doesn't improve by a single bit
• There is more value in the refinement of the implementation during the automation process
• Ninja-style Testing
• Testing to find unknown problems
• Manual
• Testing effective for iterative development
• It's difficult to find problems in planning, specifications, and design during those specific phases
• In large-scale development, the building phase and the verification phase are far apart
• Even if you think of better specs or designs during verification, you can't implement them
• Iterative development
• Break down large requirements into small units of a few days each for development
• System tests must be done frequently
• Confirming that everything implemented so far works correctly
• That's where Ninja-style Testing comes in
• A practice of performing TDD at the acceptance test level
• Development starting from acceptance tests
• Realize stories guided by acceptance tests
• Every time a story is created, conduct acceptance tests for all stories
• Think starting from "How do we test this?"
• Think about the entire development process starting from tests and keep questioning
• Manage stories with tickets
• Read through them together every morning
• Handle bugs found during development in the same way as stories
• The ticket management system is a custom one made with Ruby
• Want to package it and make some money
• Cases where Agile doesn't go well
• Because they stay at the bottom of the V-model
• Developers and testers are separated
• Just dividing the coding-related work into iterations
• Ninja-style
• Perform all steps of the V-model in every iteration
• Everyone is a developer
• Every step is done by a programmer and a tester who handles non-programming tasks
• Want to see the results in a short cycle -> Acceptance tests every iteration
• Want to tune specs and design in a short cycle
• Want to polish the product until the very last minute
• Don't postpone the difficulty of integrating with the system
• Integrate with the system even for small changes
• Do it even if it's hard, do it because it's hard
• Postponing leads to "slow-creeping development"
• Don't postpone bug fixes
• If you find a bug, stop development until the cause is understood
• Don't judge severity based on appearance alone
• A bug is just a part of a visible problem, so look for the real problem
• Postponing slows down the pace of development
• If you don't solve the current problem, you can't find more advanced problems
• Confront 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 or recently fixed tickets
• Algorithm
• Everyone tests
• Today's recommended tests
• Recommend only the amount that seems doable in a day
• Became able to fix seemingly difficult problems without hesitation
• Peace of mind that even if something happens, it can be found and fixed
• Actively look for differences from the ideal
• Everyone develops while asking what a good product is
• Similar changes occurred in people who joined later
• Timebox hypothesis
• Easier to think when there is a period
• 1 hour, 1 day, 1 week
• Remaining documents
• Read them when forgotten
• Usage
• Happy to see the expected product behavior written at that time
• Tickets aren't orders or slips
• Useful for newcomers
• Together with seniors
• Product specs, behavior, etc.
• Repeating that is good

"Rails Applications and Performance Tuning: A Case Study of Supporting a Mobile Order System with 50,000 Requests per Second" by Okumoto-san

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 an app and delivered it as a junior high student to earn technical college admission fees
• Design and mindset with performance in mind
• API-based Rails
• Building up from the basics
• Avoiding N+1 queries and slow queries
• Computational complexity and fast algorithms
• Not everything is solved at the application server level
• The Web is a mixed martial arts of architecture
• Being conscious of design from the start
• Query and table design that prevents N+1
• Design of paths and controllers
• Caching strategy
• CDN/Application cache
• N+1
• Latency increase due to communication cost with the DB
• Running Bullet gem in CI as well
• Caching by CDN is a wonder drug
• Difficult to add later
• Consider caching for APIs that don't depend on individuals
• Effectively reduce the load on the Rails server
• Watch out for information leakage due to caching
• Understand Cache-Control / Vary / ETag headers well
• Understand the behavior of each provider
• Separate paths and controllers to be cached by CDN
• Configure CDN not to cache api/private/*
• Operate simple rules that make it easy to set up guardrails
• It gets tough when you seriously start considering CDN caching
• stale-while-revalidate is recommended as a workaround
• Returns old cache until revalidation even after expiration
• Cache misses don't occur frequently even with short settings
• Respond to CORS via CDN
• Cases where preflight requests occur
• It's wasteful to respond to small requests with Rails
• Consider caching or responding via CDN
• Effectively making users wait
• Design without compromising user experience
• If it's a server error, users will start inquiring
• "Currently busy. Please wait a while and try again." Conveying what the user should do
• Education of users and clients is also important
• Load testing
• Scenario testing
• Simulating requests from user usage scenarios
• Actual browser behavior
• HAR files
• Some tools can reproduce what was saved in Chrome's network tab
• Measurement
• Aggregate response times per path at a minimum
• APM is better to have
• Mock external APIs to avoid putting load on them
• Testing with HTTPS turned off
• Performance of the side putting the load won't be sufficient
• Watch out for warming up the load balancer
• Check the overall error rate
• Check error rates per endpoint
• Tuning
• Cost and business impact
• Avoiding service downtime
• User experience
• Infrastructure cost
• Reducing engineer workload
• Tune in the order of App/DB/Web/LB/CDN
• When it's slow, it's usually your fault
• Start from endpoints with response times slower than average
• Potential to make it 100x faster > 1000ms
• Endpoints with high (number of requests x latency)
• 2-10x
• Analyze PostgreSQL execution plans with GPT
• Parameter tuning
• Cannot be generalized as it depends on the nature of the application
• The goal is to maximize the use of computational resources
• Tweak at the very end
• "Performance Tuning for Deployment" in Rails Guides
• Don't lose sight of the goal setting
• Start from where you can roughly and effectively improve
• Experience design involving users and clients