Рецензии на книги издательства «O'Reilly Media»

Книга описывает административные и организационные процессы при работе с данными. Технических деталей вообще нет, все очень верхнеуровнево. Рецептов как начинать эти процессы вообще нет, описывается как уже должно все быть. Видимо целевая аудитория - это C-level в больших компаниях. Я эту книгу вообще не понял (видимо, не дорос). Единственно, что запомнилось из интересного - в Google есть должность Data Governance Tsar - да, именно "царь" - так и называют.

Для меня, как программиста, всегда были два топовых издательства - Manning и O'Reily. Manning - это всегда знак качества, всякую туфту не печатают. А вот O-Reily может похвастаться только прикольными картинками животных на обложках. Вот и в этом случае на обложке - какой-то моллюск, а внутри заложена свинья.

Эта книга от некоего архитектора, который в ней будет учить как строить безопасные масштабируемые сервисы. Присутствуют описания личных факапов (из-за сбоя сервиса иконок слетела финансовая система). Описания личных историй успеха отсуствуют, а присутсвует сборная солянка разрозненных общепринятых практик и подходов, которые вместе трудно собрать. Ничего нового, кроме банального "учитывайте риски" и "мигрируйте в облака" тут нет.

За банальщину - спасибо. Больше - не за что.

Всем известно, что Python очень тормозной. Но то, что он тормозной, не делает его плохим - за счет простого синтаксиса и наличию большого сообщества и богатой экосистемы, на нем в разы быстрее можно писать сервисы. Make it work, make it right, make it fast - авторы книги рассказывают, как сделать "make it fast" если ваш проект написан на питоне.

У книги хорошая структура - есть вменяемое введение, которое в целом описывает проблематику производительности. После введения уже следуют советы, как ускорить код на питоне за счет выбора типов данных, потом за счет мультипроцессинга, диалектов вроде Cython, и совсем уж тяжелой артиллерии типа CUDA. 

Книга будет полезна всем миддлам и сеньорам питонистам, для которых три буквы GIL являются настоящим источником боли.

Уже читал книжки этого автора.  В целом из-за избытка воды и отсутствия конкретики и кейсов книга заслуживает 3 балла, но, как и в другой его книге, здесь есть алмаз, ради которого и пятерки не жалко. А именно - его понимание стратегии, описанное в самом начале определение стратегии. Поэтому будет "четверка".

Стратегия это искусство накопления силы. Это симбиоз видения будущего, принципов и плана действия.
НО! Стратегию мало иметь - ее надо доносить, и это один из самых сложных моментов бизнеса - как донести сложную идею до всех, чтобы она стала общим стержнем. И дальше он приводить кучу разных техник вроде SWOT-анализа, Impact mapping, Матрицы Эйзенхауэра и т .д. которые можно применять для анализа и донесения стратегии. Их польза для выработки настоящей стратегии (на мой субъективный взгляд) сомнительна, но сам факт знания о них будет полезен.

Основная аудитория, это наверное всякие менеджеры и техническое рукводство (и не обязательно в IT), но для не С-level executives книга тоже будет полезна.

Довольно неплохая книжка про практики Software Engineering в Google. Будет интересна CTO, менеджерам, специалистам по тестированию и devops. Было интересно прочитать какие челленджи есть у организаций, которые работают действительно с большими кодовыми базами (в отличии от т.н. "галер", где калибр кода мелкий и средний :).

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

Главный принцип, который мне показался близким - No haunted graveyards - не надо превращать критичные участки кода в "кладбища", на которые все боятся заходить.  Максимальный уровень ревью и пересмотра решений, никакой пощады legacy, покрытие тестами всего, что можно покрыть.

Книга немного странная, потому что пытается достичь 2 целей - 1) научить программировать тех кто начинает и 2) дать представление об особенностях языка Julia тем, кто уже умеет програть. Для первой цели книги не хватает теоретического базиса и более глубокого рассмотрения основных вещей. Для второй цели - погружение в язык слишком поверхностное, не раскрывающее значимые аспекты языка, а только базовый синтаксис.

Вообщем, могу порекомендовать эту книгу тем, кто хочет за один день составить представление о Julia, новичкам точно не посоветую.

А так если, не брать во внимание эту книгу, то Julia очень интересный язык с макросами и возможностью задания своих кастомных операторов и крутой научной стандартной библиотекой

Довольно странная книга.

В теории основная целевая аудитория - инженеры по знаниям - люди, которые занимаются созданием схем и наполнением для "графов знаний". В вопрос на который она обещает дать ответ - "как правильно организовать и наполнять такую структуру". Но по хорошему - эта книга опоздала уже лет на 10: зачем нам создавать эксплицитные схемы, когда всякие эти нейросети уже давно умеют в нечеткое тензорное представление объектов? Зачем нам учить "инженера по знаниям" решать дискретные дилеммы, вроде "кто ближе к утконосу - утка или бобер", когда индустрия уже во всю приняла отказ от дискретности , субъективности и однозначности в пользу градуальности и полной опоры на эмпирическую природу данных, на которой происходит работа.

Это я не про то, что такие графово-онтологические структуры не нужны, а про то, что форма и содержание работы с ними требуют пересмотра, а автор подзастрял немного в прошлом. Вообщем, книга очень скучная и занудная (как и моя рецензия :)).

Очень добротная книга о том, как делать системы основанные на передачи сообщений. В книге рассмотрен, ну наверное, каждый аспект:

- Обоснование подхода "Синхронный vs Асинхронный" и "Сообщение vs Событие"

- Проблемы агентов в системах на ивентах

- Динамическая эволюция схемы событий

- Распределенные миграции

- Связь шины событий и хранилищ конкретных микросервисов

- Сильные и слабые стороны событийных фрейморков

Произведение довольно объемное, и все за один раз конечно не осилить, наверное эту книжку мне придется читать еще не один раз.

Весьма странная книга.

Начало очень интригующее. Автор поднимает проблему неудач в разработке и ставит самой вероятной причиной "неудачу языка" (language failure), т.е. команда проекта не смогла сформировать общую понятийную базу, для того чтобы на ее основе из этих кирпичиков создавать систему как "лингвистический объект". Автор широко цитирует Жака Дерриду и его идеи деконструкции как главный инструмент семантического моделирования. Отмечу что подобный подход используется в Domain-Driven-Design, который является более приземленной практикой без опоры на философию, но в книге почему-то вообще про это ни слова.

Также автор интересно описывает роль технического директора, как "дизайнера семантики", который с опорой на техническую эрудицию вырабатывает и доносит смыслы до всей команды через разные аналитические артефакты.

Кроме этих двух интересных мыслей (обсуждение которых занимает 15% книги), в книге больше нет вообще ничего - все остальное это какой-то набор советов от "деда", которые никак не увязаны с его программными принципами. Он пишет, типа, делайте микросервисы, не забывайте про SOLID и прочее. Так например в одной из частей автор начинает хвалить Cassandra и рассказывать ее технические приемущества, при это больше про конкретные инструменты разработки не пишется. Это что, "product placement" что ли?. Ну если ты пишешь про какие-то базовые вещи и философские основы создания кода, зачем спускаться на такой уровень?

Вообщем по хорошему, книге надо ставить 2, но за интересные идеи про "неудачу языка" и креативный характер работы тех.директора накину один балл.

Очень добротная книга про DDD - предыдущие книги по этой теме, которые я читал были очень свалены или в разработку (тактический дизайн) или в аналитику (стратегический дизайн), но эта книга очень умело их соединяет. И прежде всего эта книжка дает правильный фокус на самое, на мой взгляд, главное в DDD - правильное проведение границ. Посмотрите какие границы присутствуют в моделируемой области, выработайте общий язык и реализуйте эти границы в коде.

Отдельный респект за рассмотрение похожих подходов и их отличие от DDD - микросервисы, событийная архитектура, аналитические приложения.

Это удивительная книга. Когда я с ней познакомился, не было еще никаких HuggingFace Transformers, и spaCy не было, даже Word2Vec не было. Но проблемы, которые эта книга ставила, и поясняла, для своего времени (конец нулевых) были довольно прорывными. Именно эта книжка меня "вывела в люди" и дала толчок как специалисту.

Разумеется, NLTK устарел и ему не угнаться за HuggingFace. Но это не значит, что книга потеряла свое педагогическую ценность. В книге все технологии и подходы разжевываются и объсняются. Кроме этого книга учит не только NLP, но еще и Python как таковому, позволяя что-то делать с нулевого уровню любому интересующемуся вопросами компьютерной лингвистики.

В защиту того, что она по-прежнему актуальна, скажу следующее: Легко, когда у тебя волшебная функция, которая все делает, и книжка учит тебя только правильные функци вызывать, но самому их не писать. Сложнее - когда надо погружаться в сложность, принимать ее и работать с ней. Этим эта книжка и выгодно отличается даже сегодня от все возможных "Deep Learning in NLP", вот за это ее и ценю.

Очень дельная книга о применении принципов предметно-ориентированного подхода для тех, кто пишет на Python.

Книга очень хорошо структурирована - имеется пример сквозной проекта, который с раскрытием новых тем улучшается, подсвечивая тем самым преимущества DDD. Рекомендуется всем python бекенд-разработчикам для понимания того, в чем состоят узкие места масштабируемости, как на нас влияют фреймворки и почему Django порой не самый лучший выбор.