The books from the previous lesson set the depth; the online ecosystem sets the rhythm. The internet holds excellent material on design patterns — interactive references, blogs by the original authors, conference talks, refactoring katas — and also tons of shallow, copied, or outdated content. This lesson does not hand you a list of links to hoard in your bookmarks: it gives you a taxonomy of resource types, criteria for evaluating each one, and, above all, a deliberate-practice plan with PideYa as a personal project — because patterns are not learned by watching videos but by writing code.

1. The types of online resource (and what each one is for)
2. Interactive references: refactoring.guru and sourcemaking
3. Author blogs: martinfowler.com and company
4. Official documentation as a source of real patterns
5. Course platforms: how to evaluate without a shopping list
6. Talks and channels: GOTO, Devoxx, and the conferences on YouTube
7. Katas and deliberate practice
8. PideYa as a personal project: the capstone exercise
9. Outdated content: how to spot it

Each type of resource serves a different phase of learning. Using the wrong type for the wrong phase is the main source of frustration:

refactoring.guru is today's most popular visual reference for the GoF patterns: every pattern with its problem, solution, diagrams, pseudocode, and examples in several languages (Java included), plus a catalog of refactorings and code smells aligned with Fowler. It is ideal as a second opinion after this course: when you're unsure about a pattern, check its entry against what we built in PideYa.

sourcemaking.com is its spiritual predecessor: same territory (patterns, anti-patterns, refactoring), older style. Useful above all for its anti-pattern catalog, which extends our lesson from module 5.

A warning that applies to both: their examples are deliberately small and didactic. The risk is memorizing the miniature and failing to recognize the pattern at full scale — which is exactly why this course insisted on a continuous domain like PideYa.

martinfowler.com is probably the single most valuable site in this lesson: the PoEAA catalog online, the bliki with canonical definitions (from "Microservices" to "StranglerFigApplication", the origin of the pattern we used in module 6), and long-form articles on refactoring, CI/CD, and evolutionary architecture. Read it whenever a term from the course calls for depth: there is almost always an entry of his that pinned it down.

Robert C. Martin's blog (Uncle Bob) complements it with strong opinions on SOLID principles, clean architecture, and professionalism. Same as with his books: valuable material, forceful tone — read it with the independent judgment you have already trained.

One habit that sets apart people who truly master patterns: reading official documentation looking for the pattern. We practiced it in module 5 and it is worth keeping up:

• JDK Javadoc: Iterator, the factory methods of List.of/Collectors, the Builder in StringBuilder and HttpRequest, Observer in java.util.concurrent.Flow, Decorator in java.io.
• Spring documentation: Template Method in JdbcTemplate, Proxy in AOP and @Transactional, Singleton as the default scope, Strategy throughout its pluggable configuration.

Official documentation is never outdated relative to its own version, and it shows design decisions made by expert teams under real constraints: a free patterns course hiding in plain sight.

On Coursera, Udemy, or Pluralsight there are good and bad patterns courses, and the catalogs change constantly, so rather than recommending a title, here is the evaluation checklist:

• Which language and version? A patterns course "in Java" recorded on Java 6 will ignore lambdas, records, and Optional, and will teach you solutions that are needlessly verbose today.
• Domain-based examples or miniatures? Be wary of courses where every pattern lives in its own isolated toy example (geometric shapes, animals). You know from experience that the value lies in a continuous domain.
• Does it cover when NOT to use the pattern? A course that only sells advantages has not understood module 5 of this one. Trade-offs are half the content.
• Last-updated date and recent reviews? Reviews from five years ago describe a different course.
• Are there coding exercises, not just video? Watching someone code is not coding.

If a course passes this checklist, it is probably worth it, whatever the platform.

The YouTube channels of conferences such as GOTO and Devoxx publish thousands of quality talks for free: it is where the industry debates microservices, DDD, evolutionary architecture, or the limits of patterns, often delivered by the very authors of the books from the previous lesson. How to make the most of them:

• Use them for perspective, not for fundamentals: a 45-minute talk inspires and orients, but it does not replace practice.
• Search by course concept ("circuit breaker", "event sourcing", "hexagonal architecture") and filter to the last 2-3 years for trends — with no fear of the classic talks for the fundamentals.
• Practical rule: for every talk you watch, one one-line note with the applicable idea. Without the note, the talk was entertainment.

Deliberate practice — short, repeatable exercises focused on one specific skill — is to design what scales are to the piano:

• exercism: exercises by language with community mentoring; its Java track is a good gym for idiomatic style.
• codewars: short katas by difficulty; useful for fluency, less so for design (the problems are small).
• Refactoring katas: the most valuable for this course. The Gilded Rose — which we already suggested in the refactoring lesson of module 5 — is the queen: horrible legacy code with tests, perfect for practicing the "test → refactor → pattern emerges" cycle. Other well-known ones: the Tennis Refactoring Kata and the Trip Service Kata (from the ecosystem of Emily Bache and Sandro Mancuso, whose repositories are easy to find).

The key to a kata is not finishing it but repeating it: the second time with a different pattern, the third with strict TDD. Repetition with variation is what cements judgment.

The best "online course" you can take now is not on any platform: it is implementing PideYa for real. Throughout the course you saw fragments; building it in full will force you to make all the decisions a course makes for you. Suggested plan by stages:

Rules of the game: tests from the start (module 6, TDD), every pattern introduced when the code asks for it (Kerievsky, module 5), and a short ADR for every design decision. A repository like that is also the best design portfolio you can show in an interview.

Online content ages without warning. Warning signs when evaluating a tutorial or course:

• Double-checked-locking Singleton presented as "the" solution, with no mention of enum or DI containers: material predating the modern conversation (our critique from module 2).
• Java without lambdas where a lambda would do (Strategy or Observer with ten-line anonymous classes): pre-Java 8, meaning over a decade old.
• "Microservices are always better" (or any "always"): the industry pendulum has already swung back; serious material talks about trade-offs, as we did in module 6.
• Frameworks or versions you no longer recognize in the examples, or screenshots of tools with interfaces from many years ago.
• A total absence of tests in a refactoring tutorial: it contradicts the very definition of refactoring.

Spotting outdated material does not always mean discarding it — the fundamentals age well — but it does mean reading it knowing which part has expired.

• Mistake: tutorial hoarding. Fifty saved tabs and not a single finished project. Inverse rule: at most one active resource per type, and no new one gets added until the current one is closed out.
• Mistake: "tutorial hell". Chaining video courses produces a feeling of progress without real progress. The healthy ratio is roughly 1 hour of consumption per 2-3 hours of practice.
• Mistake: learning patterns from miniatures only. If all your examples fit on one screen, you will not recognize the pattern in a real system. Hence the PideYa project.
• Mistake: ignoring the content's date. A tutorial with no visible date is already a signal; run the outdatedness checklist before investing hours.
• Tip: turn everything you consume into something you produce — a note, a commit in your PideYa, a new test. Learning without an artifact evaporates.

Pick a patterns tutorial or course you have saved (or search for any one about Singleton in Java). Run it through the evaluation checklist and the list of outdatedness signs. Write a three-line verdict: would you use it? With what precautions?

Design a realistic weekly plan (state hours/week) combining at least three resource types from the opening table plus stage 1 of the PideYa project. Suggested format: week → goal → resource → artifact produced.

Do (or redo) the Gilded Rose. First pass: only small refactorings, backed by the tests. Second pass, on another day: explicitly introduce a pattern from module 4 where the code asks for it. Write down which pass felt more natural to you and why.

Exercise 1 (indicative): a typical verdict on an old Singleton tutorial: "It explains the intent well, but it uses double-checked locking without volatile (incorrect) and never mentions enum or DI; I would use it only for the pattern's motivation, never for the implementation". Note how the verdict separates which part of the resource is still valid.

Exercise 2 (indicative): an example at 5 h/week: W1 — PideYa domain (the menu as a Composite) + the Composite entry on refactoring.guru as a cross-check; W2 — extras with Decorator + one GOTO talk on OO design with a one-line note; W3 — Gilded Rose, first pass; W4 — the order's Builder + review: which pattern emerged without being planned? The plan's quality bar: every week ends with code, not just content watched.

Exercise 3 (indicative): most people find the first pass safer (the tests are in charge, small steps) and the second more tempting to over-design. If in the second pass you caught yourself inserting a pattern "because it was its turn" rather than because the code asked for it, you just lived a small-scale version of the anti-patterns lesson from module 5 — that self-awareness is exactly what the kata is for.

You now know how to navigate the ecosystem: interactive references for lookups, author blogs for judgment, official documentation to see real patterns, talks for perspective, katas for muscle, and PideYa as the capstone project where it all comes together. The common thread is always the same: consume less, produce more, and distrust material that hides its dates or its trade-offs. But learning alone has a ceiling: design judgment gets sharpened by arguing with others — asking well, reading other people's code, receiving reviews. That is what the next lesson is about: Communities and Forums.