Пока нет, но я давно это планировал, и скорей всего в конце октября таки сделаю. А что вы имеете в виду под нативным сертификатом?

Спасибо!

Thanks, Murilo! We're going to have a huge update for the design patterns section in September. Until then, I apologize for a huge number of errors and imperfections you might encounter in that section at the moment.

Thanks, Pratik!

Спасибо, Дмитрий!

Thanks, Lucas!

Я имел в виду момент, когда он зашёл на английскую версию впервые т.к. это версия по умолчанию, а потом с яндекса попадал бы на русскую, но сразу редиректился на английскую, т.к. уже стояла бы кука.

Думаю, мне стоит провести исследование по тому, как пользователи себя ведут, какие сценарии повторного посещения сайта. Моё воображение почему-то рисует только плохие сценарии, вроде того, когда юзер в первый раз вбил руками refactoring.guru и закрыл страницу (записалась английская кука), все последующие его посещения, например, из яндекса будут перебрасывать его на английскую версию, что не очевидно и не желательно.

1) Я уже давно и долго над этим думал и так и не пришёл к понимаю, как это сделать для публичной части сайта так, чтобы не было ещё хуже. Набирая в браузере "refactoring.guru", вы попадаете на публичную английскую часть, т.к. она стоит по-умолчанию. Мне самому это часто не удобно, т.к. я планировал посетить русскую версию. Но мне кажется неоправданным в этом случае редиректить пользователя на русскую версию, только из-за того, что он до этого мог ходить по русской части сайта. Что касается языка аккаунта, то он равен тому языку, с которого вы логинились из публичной части. Это сделано по причине того, внезапная смена языка в аккаунте после логина тоже выглядит странно.

2) Поправил.

3) Хорошее предложение, оставил на будущее.

• страница 229    Предложение "В идеале, этот хотелось бы поместить прямо в служебный класс...". После слова "этот" пропущено слово "код". Исправил.
• страница 249    Предложение "В этом случае запрос движется по цепи, пока не найдётся обработчик, могущий его обработать.". Немного режет взгляд "могущий его обработать", я бы перефразировал, например, так: "В этом случае запрос движется по цепи, пока не найдётся обработчик, имеющий код (условия) обработки данного запроса.". Исправил.
• страница 267    Предложение "Хорошие программы обычно структурированы в виде слоёв.". Как вариант, для интересующихся можно дать ссылки на паттерны MVC/MVP MVVM... (кстати, может имеет смысл добавить их в книгу?). Это в планах на будущее.
• страница 341    Предложение "Реализуйте их так, чтобы после каждого изменения состояния они слали оповещения...". Аналогично комментарию к странице 187. Исправил.
• страница 346    Предложение "Паттерн Состояние невозможно рассматривать в отрыве от концепции машины состояний, также известной...". Ссылка "машины состояний" на английском языке, было бы логичней приводить ссылки на языке издания (в данном случае: https://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BD%D0%B5%D1%87%D0%BD%D1%8B%D0%B9_%D0%B0%D0%B2%D1%82%D0%BE%D0%BC%D0%B0%D1%82). Исправил.
• страница 359    Предложение "...все методы интерфейса состояния должны быть реализованы по всех классах состояний.". Опечатка, нужно "...реализованы ВО всех...". Исправил.
• страница 377    Предложение "В нашем примере шаги открытия и закрытия документов будут отличаться для всех подклассов, поэтому останутся абстрактными. А вот одинаковый для всех типов документов код обработки данных переедет в базовый класс.". Комментарий: если честно, не понял данный фрагмент и поэтому не согласен, на мой взгляд, "шаги открытия и закрытия документов" как раз должны быть одинаковыми, а вот "код обработки данных" как раз уникален для каждого типа документа, и поэтому всё должно быть как раз наоборот, т.е. "шаги открытия и закрытия документов" должны быть в базовом классе (с точки зрения C# данные методы можно будет сделать виртуальными, если всё же потребуется их переопределять), а вот "код обработки данных", ввиду его различия в каждой реализации, должен быть абстрактным методом с уникальной реализацией в каждом подклассе. Если что-то другое имелось ввиду, возможно нужно перефразировать, т.к. сейчас выглядит не понятно, буду рад Вашему комментарию. Я немного подправил этот момент, но в основном там имелось в виду, что для разных видов файлов могли бы понадобится различные конструкторы объектов для чтения файлов, отсюда и нужда в разных версиях методов.
• страница 378    Предложение "Это опциональные шаги, которые выглядят как обычные методы, но не содержат никакого кода.". На мой взгляд, здесь имеет смысл дополнить, чтобы не потерять нить рассуждения, начатую в конце страницы 376, например, так: "...но не содержат никакого кода (по своей сути, это абстрактные методы базового класса не требующие реализации в конкретном контексте)." Немного перефразировал это место, чтобы связь лучше просматривалась.
• страница 378    Предложение "...хук даёт подклассам дополнительные точки «вклинивания» в ход шаблонного метода.". Опечатка, нужно "...в КОД шаблонного...". Это была не опечатка, но я перефразировал, чтобы не было неоднозначности.
• страница 380    Диаграмма. Если вспомнить старую добрую Warcraft, то ресурсы как раз собирали орки, т.е. имеет смысл поменять местами заголовки производных классов на диаграмме (и кстати, раз на 381 странице Вы пишете, что "монстры вообще не будут заниматься строительством", то, также имеет смысл убрать у них на диаграмме производного класса метод "buildStructures()") ;) Эти методы присутствуют в классе монстров, т.к. их там нужно переопределить. Отсутствующие методы в классе орков значат, что они наследуют поведение родителя. Но я согласен, что это самый слабый пример из всей книги.
• страница 402    Предложение "Распечатайте шпаргалки по паттернам и...". Ссылка "шпаргалки по паттернам" на английском языке, комментарий аналогичен к странице 346. Если бы всё было так просто :) Шпаргалок на русском, к сожалению, пока ещё не существует.

Все исправления будут на сайте/в книге в течение 15 минут.

Ещё раз спасибо за то, что нашли время составить список ошибок, я очень признателен вам за это.