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

Однако, для новичков эта книга может оказаться сложноватой. Автор, как писали ниже, часто советует как надо делать, а как не надо, но не аргументирует свои рекомендации.

Надо отдать должное книге – на обложке честно указано, что она рассчитана на читателей среднего уровня знаний, и в этом я с автором согласен. Однако, несмотря на это, обнаружилось несколько моментов, которые кажутся устаревшими.

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

Итак, подводя итог: "Изучаем SQL" Алана Боля – отличный выбор для тех, кто хочет повторить и закрепить уже имеющиеся знания в этой области. Однако, если вы новичок и только начинаете свой SQL-путь, возможно, стоит посмотреть в сторону другой литературы.

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

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

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

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

Довольно неплохая книжка про практики 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, но за интересные идеи про "неудачу языка" и креативный характер работы тех.директора накину один балл.