Форум о банкротстве и продуктах «РИТ»

[vva]

Дуглас Адамс: Автостопом по Галактике. Ресторан "У конца Вселенной"
https://www.labirint.ru/books/441764/

По непонятным причинам я лишь в 45 лет прочитал эту книгу, хотя конечно слышал о ней много лестного от знакомых и встречал много отсылок к ней, хотя и плохо их понимал. Прочитал чисто чтобы отвлечься. Отвлечься получилось "взахлёб", собственно прочитал в два присеста. Всё очень легко и по крайней мере первая часть увлекает. Хотя конечно при таком подходе какой то большой новизны для себя я не ощутил. От того что много слышал ранее и от того что очевидно идеи изначально были натасканы у других авторов, да и позднее другими же авторами растасканы.

Тем не менее налицо:
- отличный образчик лёгкого и не совсем тупого чтива,
- успешная трансформация жанра серии рассказов в жанр романа (чего судя по всему не получалось у Шекли)
- удачный перевод

Сценка с жывотным, которое специально вывели на потребу "зелёным", чтобы оно хотело быть съеденным в ресторане, всё также (а может и больше) пугает спустя десятки лет после написания

[vva]

Мартин Клеппман: Высоконагруженные приложения. Программирование, масштабирование, поддержка
https://www.labirint.ru/books/632959/

Книга довольно глубокая и в то же время отличается прямо невероятной широтой охвата. В общей сложности на чтение ушло более полугода с перерывами. Согласен с утверждением, что книгу полезно иметь на руках просто как хороший справочник. Доступно поясняются различия подходов, достоинства, недостатки и проблемы разных СУБД и других движков и компонентов и архитектур больших ИС. Перевод, как и иллюстрации более чем адекватны.

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

Также было приятно прочитать подтверждение ряда своих мыслей о том, что грамотная поддержка важнее супер-автоматизации, что золотого стандарта надёжности/производительности пока не сложилось, и что большинство админов предпочитают в случае аварий поднимать упавшие компоненты руками, а не доверять никаким автоматическим angel process, которые иногда способны лишь попросту размазать shit ещё больше.

[vva]

Антонопулос, Вуд: Осваиваем Ethereum. Создание смарт-контрактов и децентрализованных приложений
https://www.labirint.ru/books/819767/

Хорошая обзорная книга по теме. Перевод довольно адекватный, хотя листинги программ местами "съедены". С предыдущим бестселлером Антонопулоса про Bitcoin конечно книга сравнения не выдерживает и уже в предисловии позиционируется как "исследование". Очевидно, из-за слишком большого объёма материала некоторые темы раскрыты поверхностно. В середине книги совершенно искусственно и неадекватно выглядит глава о Parity (видимо увлечение Вудса на момент написания). Далее преждевременно несколько воспринимается глава о безопасности. Как справочник книга имеет шансы стать настольной.

[vva]

Кент Бек: Экстремальное программирование. Разработка через тестирование
https://www.labirint.ru/books/583040/

На поверку оказалась довольно легковесной книгой (и читается легко и тема разобрана "легко"). По большей части разбирается несколько несложных примеров и тесты для них, а также некоторые паттерны проблемы и приёмы тестирования. Всё это я более менее знал и ранее. Про тестирование ГУИ и баз данных сказано что это проблемы. Но были и некоторые интересные мне моменты. О том что тесты - это в большой мере про психологическую уверенность в коде. О том что для того чтобы тесты были постоянным инструментом разработчика, регулярно запускаемый тестовый набор должны выполняться за время не более 10 минут. О том какие тесты следует удалять. В общем и целом не пожалел что прочитал. Перевод вполне адекватный.

[vva]

https://www.labirint.ru/books/667923/
Форд, Парсонс, Куа: Эволюционная архитектура. Поддержка непрерывных изменений

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

По содержимому собственно автор топит за создание неких "функций пригодности" как инструмента контроля за системой при эволюционных изменениях. В остальном собственно анализируются разные архитектурные подходы, объясняется новый для меня закон Конвея о том что программная архитектура часто просто повторяет организационную архитектуру компании - разработчика. Про эволюцию данных сказано что обратные миграции (down) практически никогда не поддерживаются, раньше это приходилось объяснять опираясь на свой авторитет, сейчас есть на что сослаться. Хорошо разобраны разные архитектурные ловушки и анти паттерны, включая resume driven development. Закинуты интересные мне идеи генеративного тестирования, жертвенной архитектуры и т.п. Указано на рациональность наличия некоего корпоративного "паттерна микросервиса".

В общем и целом несмотря на перевод, не жалею что прочитал. Ну и понял что нужно больше работать над конвеером развёртывания.

[vva]

https://www.labirint.ru/books/788069/
Сэм Ньюмен: От монолита к микросервисам

Получил большое удовольствие от чтения. Содержание созвучно моим текущим интересам и чаяниям.

Перевод, несмотря на полторы страницы от переводчика с рассуждениями о том как стоит переводить, микросервисы или микрослужбы, всё равно местами озадачивает: автор на протяжении книги "разведывает" разные темы, постоянно описывает "рабочие потоки" в которых естественным образом участвуют "рабочие" etc. Несмотря на это, количество и наглядность иллюстраций такого уровня, что совершенно не оставляет шансов запутаться.

Автор отличается на удивление трезвым взглядам на тему и несмотря на хвастовство тем что он и придумал сам термин "микросервис", не ведёт себя как фанатичный евангелист, а постоянно на протяжении всей книги задаёт вопросы читателям "а оно вам надо?" и вообще описывает довольно системно разные проблемы и критерии от которых зависит успешность той или иной архитектуры. Например пишет о том что несмотря на манеру некоторых разработчиков считать контейнеры Кубернет предварительным условием микросервисной архитектуры, на самом деле он советует использовать контейнеры не сразу а примерно когда количество сервисов достигает десятка, да и то не "ванильный" а с какими то оболочками.

Отдельно доставило описание программы "Тестирование на унитазе" из коротких одностраничных статей, которые менялись еженедельно на стене в туалете напротив унитаза, чтобы таки заставить сотрудников читать (сын правда удивился типа у них что, сотовых нет ив туалете больше заняться не чем?). Не могу пока осознать, какой эффект это вызвало во мне больше: то ли сильно уронило моё мнение о разработчиках гугла, то ли подняло моё мнение о разработчиках вокруг меня "не из гугла". Очевидно что люди сейчас с трудом учатся чему то новому и меняют своё мнение даже в самых передовых компаниях. Собственно наверно это в том числе и есть одна из причин популярности микросервисов, чтобы каждый занимался в каком то своём узком закутке, не поднимая задницу.

P.S. пока смотрел наиболее интересные картинки, увидел что переводчик таки для разновидносте й саг кое где в скобках дал английский вариант слова "orchestrated" и "choreographed", несмотря на вроде как имеющееся в русской культуре понимание разницы в анекдотах о том что дирижёр при встрече оперной примадонны начинает ей высказывать, а вот от прима балерины старается спрятаться.