Что было в начале времени? Чем научная теория отличается от ненаучной? И что общего имеют черные дыры и сотворение мира? Это часть вопросов, свой ответ на которые даёт Хокинг.
Книга очень понравилась.
Хокинг последовательно описывает как устроена вселенная с точки зрения современной (на момент написания книги) физики. И что ещё более ценно не только это, но и развитие представлений о мире, времени и пространстве. Как мы пришли от птолемеевской картины мира с Землёй в центре вселенной к современной сложной модели с относительным временем, корпускулярно-волновым дуализмом, кварками и античастицами. При этом, как автор и обещает в начале книги, в ней нет формул и для понимания хватает моих давних, ещё наверно школьных знаний физики.
Начинаясь как обычный приключенческий роман, во второй части он переходит к более сложным и даже философским вопросам. Основание верит в план Селдона, который должен привести к созданию новой империи за 1000 лет, но знает ли оно что именно это должна быть за империя? Есть много путей, которым можно прийти к новой империи, но только один — к той, которую хотел построить Селдон. И кто сказал, что эта империя будет торжеством демократии и равенства, а не деспотичным правлением горстки избранных психологов? И если Второе Основание существует и обеспечивает движение к намеченной Селдоном цели, то есть ли у жителей и правителей Первого свобода действий? Не только коллективная и на исторических отрезках времени, но и индивидуальная?
Galaxy! When can a man know he is not a puppet? How can a man know he is not a puppet?
Книга представляет собой обзор паттернов разработки распределенных приложений используя контейнеризацию.
Начинается она с обзора паттернов для случаев, когда контейнеры располагаются на одной физической машине.
Sidecar — второй контейнер рядом с основным, расширяющий его функциональность. Как теория ок. Примеры автор приводит сначала про добавление поддержки https к легаси системе — наверно имеет право на жизнь, если легаси настолько старое, что и правда засунуть его в контейнер будет проще. Следующий пример понравился уже сильно меньше — контейнер который добавляет мониторинг соседнего и некую веб морду с данными о использовании ресурсов. Имхо для таких целей нужен все таки какой-то централизованный мониторинг причем с графиками по времени и т.п. типа как даёт заббикс. Поэтому пример выглядит нежизненным. Третий пример про реализацию доставки изменений через гит репозиторий посредством контейнера который в цикле делает пулл из него. Ну такое. Имхо правильным будет всё-таки когда доставку изменений производит сторонняя система по событию пуша в гит репозиторий, а не трата ресурсов на пулл в цикле.
Дальнейшие рассуждения про то какими должны быть контейнеры, чтобы их можно было переиспользовать хороши, но в целом вытекают из правил для любого модуля, только с поправкой на реалии контейнеров. Внешний интерфейс, документирование, стабильность API и вот это все.
Ambassador — через второй контейнер происходит взаимодействие с внешним миром. От первого примера про шардинг у меня знатно подгорело. Пример собственно про то, что сделаем шардинг редиса так, чтобы для приложения он был как будто один и нам его менять не пришлось. Поднимают 3 независимых редиса, и контейнер-прокси запросы к себе распределяет на них. Ааааа! Кластер редиса делает это сам по себе из коробки, давая при этом ещё и отказоустойчивость. А если заменить редис на какую-то не key-value базу — то там так просто на прокси запросы от приложения не поделишь, совсем приложение не трогая. Другие примеры — сервис-брокер для сервис-дискавери и канареечный релиз / дублирование продакшн трафика на тестовое окружение. Первый да, могу понять, если сервис-дискавери делается не посредством днс. Со вторым так и не смог для себя придумать, когда это было бы полезно делать со стороны клиента, а не сервера принимающего запросы — тестировать то мы будем изменение поведения сервера.
Адаптер. Похоже на амбассадора по сути, но смысл использования — предоставление интерфейса, который основной контейнер не предоставляет. Тут у меня наконец-то вопросов не возникло. И кейсы с мониторингом редиса и изменением формата логов понятные.
Дальше в книге начинаются паттерны для распределенных систем и там уже все выглядит вполне понятно, но в то же время и весьма лайтово (сильно лайтовее книги с кабанчиком). Рассматриваются шардирование, реплики стейтлесс сервисов, scatter/gather паттерн (отправка запросов сразу на несколько серверов и объединение ответа от них в ответ пользователю). Примеры по прежнему не впечатляют, но уже скорее из-за своей простоты. Например пример где делают консистент хешинг на nginx, но при этом на фиксированном в конфиге числе апстримов, учитывая что до этого шла речь про изменение числа шардов, ожидал бы тут какой-то пример, где это самое число шардов можно было бы менять на лету.
Следующая глава посвящена FAAS — function as a service. Общие рассуждения о применимости, удобстве и экономической обоснованности при разной нагрузке полезны. А вот первый предлагаемый пример использования странный — предлагается декоратор по такой схеме: пользователь -> декоратор -> основное приложение. Если декоратор условная лямбда на Амазоне, то если ответ идёт по тому же пути, то декоратор висит все время запроса и мы платим за все это время. Чтобы эта схема была экономически не провальна, мне кажется, нужно усложнять получение ответа от основного приложения в таком сценарии, что никак не согласуется со сценарием — просто добавим декоратор на FAAS, чтобы не править основное приложение.
Выбор мастера и владение (ownership) ресурсом. Первая глава в книге, к которой у меня нет претензий. Более того — она дала мне очень важный инсайт, т.к. на самом деле речь в ней идёт о распределенном локе. Распределенные локи активно используются у нас в коде ( реализованы через редис ). И почему-то раньше я не задумывался о том, чтобы использовать их же для того, чтобы только один наш демон читал определенную очередь (по пулл модели), а думал как-то дополнительно прикручивать zookeper и какой-то более сложный механизм выбора мастера. Глава дала хорошую пищу для размышлений. Также полезной была мысль, что хотя современный оркестратор способен обеспечивать некоторые гарантии fault tolerance, перезапуская упавший контейнер и перенося его с упавшей машины — этого недостаточно при частом деплое.
Последние три главы посвящены очередям и обработке сообщений. Хорошо описано, хотя как по мне поверхностно. Но полезно было взглянуть на это с точки зрения использования контейнеров как замены библиотек.
Общее ощущение от книги — она простовата и наверно скорее полезна как обзорная для новичков. Примеры скорее учебные и не очень близки к реальным. Но в целом прочитать было полезно.
Смешанное впечталение осталось от книги, как от пирожного с песком 🙂
Так что дальше + и — в порядке в каком они приходят в голову:
+ много ссылок на исследования по работе мозга — почти все из них я уже слышал (не знаю, можно ли это засчитывать в минус книги, но ее ценность для меня оно явно снижает) — какая-то сумбурность, есть ощущение как будто автор просто скачет с одной мысли на другую, без особой связи между ними (особенно между главами) — сначала вообще хотел бросить читать, т.к. рассуждения вида «ваше сознание ничем на самом деле не управляет, так что на свою жизнь вы влиять не можете, хаха» — мне не нравятся и я с ними не согласен. — ближе к концу книги автор как-то переходит на прямо противоположное утверждение, что надо прокачивать мозг, заставлять его думать, при этом или он так и не объяснил, как это сочетается со сказанным им в первой главе, или объяснил как-то так, что я это объяснение не понял и упустил. + но при этом понравилась метафора, что сознание — это как фонарь освещающий какую-то часть темноты, в которой на самом деле продолжают параллельно происходить множество других процессов. + понравились рассуждения про мультиличность, что не бывает личности самой по себе, а проявляется она в социальном взаимодействии + также объяснение прокрастинации в соц. сетях и сравнение ее с подсадкой на наркотик и экспериментом с крысой и кнопкой, возбуждающей дофаминовые центры в мозгу (хотя сравнение и не новое и уже встречалось, но тут как-то хорошо написано) — ну и несколько раздражала сама манера подачи информации, когда какие-то факты и рассуждения перемежаются снисходительными обращениями к читателю, как будто от лица некоего гуру. Возможно так оно лучше продаётся, не даром автор написал не одну книгу, ставшую бестселлером, но я не в восторге.
Вторая часть классической серии Азимова про Основание.
Книга на самом деле состоит из двух независимых историй. Первая продолжала стиль и характер истории первой книги — космический эпос, стагнирующая империя и Основание, которое побеждает несмотря на всю опасность за счёт внутренних процессов в самой империи.
А вот вторая часть действительно удивила, реальный слом стандартного шаблона — вот мы хорошие люди, в ходе книги происходят всякие сложности, но в конце мы побеждаем. Начинаю понимать популярность серии и берусь за третью книгу
Долгие годы источником новых знаний в IT для меня был хабрахабр, но или я его перерос или он в последние годы скатился, но что-то стоящее там попадается всё реже и реже. Настолько, что становится жалко времени, которое тратится на перелопачивание новых статей и невольное залипание во всяких статьях, обсуждающих текущие новости, ценность которых, если смотреть даже с небольшого отдаления, стремится к нулю. Достойной замены я ему пока не нашёл, некоторое количество людей в твиттере и медиуме — это всё ещё не то, да и соотношение польза/шум в твиттере не сильно лучше хабра, даже если стараться подписаться на кого-то, от кого прилетает время от времени интересный материал.
В итоге пока решил переключиться на книги, тем более, что книг по специальности я прочёл не так много — в основном потому, что читаю я в основном с читалки или телефона, и специальную литературу в pdf и там и там читать неудобно.
Но технологии не стоят на месте 🙂 Оказалось, что весьма удобную оболочку для чтения книг даёт в своём приложении O’Reilly. К тому же в полном соответствии с мотивационными теориями, если ты за что-то заплатил, то твоя мотивация это использовать заметно повышается 🙂
Это была присказка, а первой прочтённой мной на платформе O’Reilly книгой стала классическая книга с кабанчиком, о которой дальше и пойдёт речь.
Книга действительно настолько хороша, как все о ней говорят. С моим опытом не могу сказать, чтобы там было что-то принципиально новое для меня, но всё равно с некоторыми технологиями я плотно никогда не работал, а о некоторых моментах тех техологий, которые использую в работе, давно не задумывался и освежить их в памяти было очень полезно.
Дальше крупными мазками по содержанию.
Книга состоит из трёх частей. Первая — представляет собой обзор способов хранения и обработки данных в пределах одной машины:
Какие бывают БД, как они развивались и для каких задач лучше подходят. Тут очень интересным было читать про графовые БД, так как я сам плотно с ними не работал. Особенно порадовало сходство Datalog и пролога.
Как БД хранят данные внутри себя, append-only logs и структуры для индексов — очень подробное и понятное описание, мне конечно тяжело судить, но показалось, что настолько понятное, что его можно было бы читать даже без какого-то бэкграунда
Форматы хранения данных — текстовые, бинарные, рассуждения о forward и backward compatibility. Тут интересным было читать про Avro (опять-таки, потому что я с ним не сталкивался ранее 🙂
Вторая — распределенные данные и проблемы возникающие при этом
Репликация. Очень подробный обзор — синхронная / асинхронная, с одним лидером и без лидера, проблемы с лагом репликации и способы их решения
Транзакции. Не просто что такое и зачем, но и трейдоффы, уровни изоляции и как они релизовываются на низком уровне.
Проблемы распределённых систем. Одна из самых полезных глав. Что и как может пойти не так — нестабильные сети, процессы на паузе, ненадежное время, разница между монотонным и календарным временем, Byzantine faults (не могу придумать как это корректно перевести на русский таким же коротким термином — возможно, в русском нет подобного термина для неполадок, вызванных поведением частей системы, которые нарочно врут и им нельзя доверять)
Распределенные транзакции — двухфазный коммит, алгоритмы консенсуса (без глубокого погружения, но общие принципы, и какие существующие инструменты их реализовывают)
Третья — пакетная и потоковая обработка данных
Пакетная обработка (batch processing) — MapReduce и описание какие есть способы осуществления джойнов данных при этом + рассуждения о том насколько оно похоже на Unix утилиты
Потоковая обработка (stream processing) — переход от пакетной обработки, message-based и log-based источники данных, change data capture, event sourcing и как и везде в книге — рассуждения о проблемах и трейдофах при потоковой обработке данных, а также как сделать её максимально ошибкоустойчивой (микробатчи, идемпотентность)
И последняя глава состоит из рассуждений автора о будущем обработки данных и этических вопросах. Второе неинтересно (т.к. ничего нового, всё те же опасения, и гос. регулирование нас спасёт), разве что стоит отметить сравнение текущего положения со сбором и обработкой данных с ранним капитализмом — детским трудом, 12-часовым рабочим днём и т.п. А вот техническая часть главы выглядит интереснее — кругом сплошное телевидение сплошные стримы и данные порождаемые из данных. Интересна идея замены двухфазного коммита на единое сообщение с бизнес-транзакцией пользователя, на основании которой уже все системы (базы данных, поисковые индексы, очереди сообщений и т.п.) делают нужные им изменения состояния, но автор сам отмечает, что тут есть большая проблема с read your own writes, которая по его мнению как-нибудь будет решена (мы же о будущем мечтаем).
В целом очень доволен, что прочёл. Главный плюс книги вижу ещё и в постоянном внимании к тому, что может пойти не так, и какие проблемы есть у таких и эдаких решений. Какая цена будет чтобы их избежать. И не дешевле ли будет позволить системе иногда ошибаться и разработать механизм устранения ошибок постфактум, особенно учитывая то, что информационная система работает с реальным миром, в котором ошибки все равно происходят, поставщики не доставляют товар (даже если он идеально записан во все БД), а сотрудники забывают про задачи клиентов (даже записанные с максимальной надёжностью и доставленные по всем каналам без потерь).
В предверие выхода сериада от нетфликс решил таки прочитать знаменитый цикл Азимова. Читать решил не в «правильном» хронологическом согласно повествованию порядке, а в порядке выхода романов — так мне показалось будет правильнее 🙂
В прошлый раз я пытался читать Основание лет 10 назад в оригинале и оказалось сложно и не зашло (настолько, что бросил, недочитав первую книгу). Видимо английский с тех пор у меня улучшился, т.к. сейчас язык показался не сложным (особенно если сравнивать с каким-нибудь Питером Уоттсом) и я получил настоящее удовольствие от чтения.
Да, чувствуется, что книга написана давно — технологии ядерной физики как верх научного развития, и никаких ИИ, виртуальных реальностей и генной инженерии 🙂 Сравнивая с лучшими образцами более поздней фантастики, история с одной стороны простовата, но с другой — не напрягает и захватывает. Замечательный сплав космооперы (галактическая империя, тысячи миров, межпланетная политика) с космическими приключениями в духе Светлячка (торговые корабли, личная хитрость капитанов и лидеров, находящих неожиданные решения и выходы из ситуаций). То что надо для ненапряжного чтения 🙂
Боги живут среди людей, утратив почти все имевшиеся у них силы, так как люди в них больше не верят.
Идея, как и прописанный мир — хороши, а вот сама история не увлекает — половину книги главного героя несёт по течению и он сталкивается с различными богами, от которых несёт упадком, а во-второй половине начинает внезапно что-то происходить и раскручиваться, но и сами повороты сюжета и то, чем все заканчивается оставляют скорее ощущение разочарования.
Наверно Нил Гейнман просто не мой автор 🙂 Т.к. подобные же ощущения в свое время были от Neverwhere — вроде и мир необычный и сюжет закручен, но как-то всё читается через силу и не увлекает. А в Американских богах дополнительным минусом были описания всяческой человеческой жестокости и мерзостей, которые я и не люблю и сюжету они тут на мой взгляд никак не сопутствовали и можно было без них обойтись.
Книга представляет собой сборник советов и правил как писать понятный текст в информационном стиле.
У книги есть несколько минусов:
авторы очень безапелляционны и считают, что их мнение единственно верное (но с другой стороны сам жанр бизнес-книг к таком подталкивает)
у них профдеформация и им кажется, что все тексты — это реклама и инструкции в каком-либо виде (тут особенно пригорало с своветов как оформлять заметки о путешествии 🙂 )
вместе с тем, как надо писать тексты, они проталкивают свою философию, что всегда надо писать правду, причём даже приближаясь к резать правду-матку. Подход похож на то, что пропагандирует Далио в «Принципах», но там он хоть оговаривает, что «да, это не всем подойдет, но я считаю, что правильно так»
Но если оставить за скобками эти моменты и понимать книгу, как советы как писать рекламу, объявления и инструкции, так чтобы это было понятно — то книга очень полезная. Содержит кучу практических советов как сделать текст понятнее и полезнее, начиная от того какие слова / конструкции не стоит использовать и заканчивая тем, как в целом строить текст. Я её слушал, но правильнее было бы всё-таки читать — на слух некоторые советы про абзацы и структуру текста воспринимались тяжело.
Минорные релизы MySQL 8 совсем не минорные и у этого есть как минусы (в случае проблем откатиться обратно на предыдущий минорный релиз не выйдет), так и плюсы, т.к. в них появляются новые фишки и улучшения.
В 8.0.17 к примеру завезли оптимизацию запросов с NOT EXISTS:
The optimizer now transforms a WHERE condition having NOT IN (subquery), NOT EXISTS (subquery), IN (subquery) IS NOT TRUE, or EXISTS (subquery) IS NOT TRUE internally into an antijoin, thus removing the subquery.
Пример, имеем запрос:
SELECT task.TaskID FROM contact INNER JOIN login ON login.LoginID = contact.LoginID INNER JOIN task ON task.TaskID = contact.TaskID LEFT OUTER JOIN taskstar ON taskstar.TaskID = task.TaskID AND taskstar.LoginID = 858636 INNER JOIN taskaccess accesslogined ON task.TaskID = accesslogined.TaskID AND accesslogined.LoginID = 858636 WHERE 1 AND contact.ContactBool_1 = 0 AND contact.ContactSpam = 0 AND task.TaskType = 4 AND contact.ContactIsDeleted = 0 AND task.TaskIsDeleted = 0 AND (NOT EXISTS(SELECT 1 FROM task WHERE ClientID = contact.ContactID AND task.TaskIsDeleted = 0 AND (task.TaskType = 0) AND task.TaskStatusSetID = 57450) ) GROUP BY task.TaskID ORDER BY task.TaskID LIMIT 0,5
Выполняем его в MySQL 8.0.16 и получаем:
5 rows in set (1 min 9.92 sec)
Больше минуты, совсем некомфортно. Обновляем MySQL и выполняем его же в 8.0.17:
