//АйТи интерн
Веселые и полезные истории из жизни давно уже не интерна. Также истории моих друзей и коллег. Совпадения с реальными людьми и событиями, конечно же, случайны. Связаться с нами - @fedor_ch
Show more1 108
Subscribers
No data24 hours
No data7 days
No data30 days
- Subscribers
- Post coverage
- ER - engagement ratio
Data loading in progress...
Subscriber growth rate
Data loading in progress...
Что у нас на приборах?
Thoughtworks - компания по разработке софта почти с 30 летней истории. Ее сотрудниками являются довольно известные личности (например, Мартин Фаулер). Компания оказала большое влияние на развитие нашей индустрии, делая вклад в open-source, развитие Agile практик и своими исследованиями и обзорами на технологии. В общем, крутые ребята с большим вкладом в нашу индустрию.
Примером этого является - TechRadar. По словам Thoughtworks TechRadar - это "путеводитель по передовым технологиям". Техлиды Thoughtworks регулярно встречаются и отслеживают тренды в IT, а потом выпускают TechRadar.
Я слежу за его каждым выпуском для того, чтобы понимать тенденции и узнавать про новые технологии, которые начнут восстание машин. Его полезном читать всем - от джуна до СТО.
В TechRadar графически сгруппированы:
- Techniques: техники (подходы), которые могут использоваться при разработке.
- Tools: инструменты для разработки и разработчиков.
- Platforms: инфраструктурные штуки.
- Languages & Frameworks: языки программирования и все что к ним относится.
Каждая группа разделена на 4 раздела:
- Adopt: однозначно можно применять в проектах.
- Trial: можно начинать интегрировать в проекты, но с определенной долей риска.
- Assess: стоит изучить технологию, провести R&D и понять как эта технология может повлиять на вас, так сказать "пощупать руками".
- Hold: нужно подождать с использованием или может быть совсем отказаться от технологии.
Также есть инструмент для создания своего TechRadar. Очень круто, если нанимающая компания имеет своей радар и показывает кандидатам. Таких компаний пока у нас мало, но их количество растет.
Подписаться и быть всегда в тренде, чтобы решать свои задачи эффективно, можно тут - https://www.thoughtworks.com/radar
Успехов!
@it_intern
Возвращаемся в эфир...
Что могу сказать? Могу только поставить реакцию "взрыв башки".
Мир теперь постоянно пересобирается и реконфигурируется по несколько раз в месяц. И как модно говорить нужно быть "гибким", а не прогибаться, подстраивать обстоятельства под себя, а не под них (Стэтхэм вошел в канал).
Я верю, что имея хорошее образование и навыки можно найти свое место в мире по все его стороны.
Я долго думал чем я могу помочь здесь обычным людям. И я нашел ответы. Про них скоро узнаете.
А я пока готовлюсь к выходу в новое место работы и запуска пары новых проектов в том числе и образовательных.
Успехов!
@it_intern
Алгосы нужны?
Когда-то давно в одном из каналов прочитал о книжке Джона Бентли “Programming Pearls”. Недавно добрался до нее, вычитал одну любопытную историю, ставящую под сомнения некоторые “договоренности” в IT.
Физик Андрей Аппеля симулировал движение 10 000 планет. По его подсчетам работа "брутфорсного" алгоритма заняла бы несколько лет. Поэтому ученому пришлось углубиться в тюнинг производительности программы.
Ему удалось переписать выполнение 1 шага алгоритма с
O(N^2) на O(N*logN), что дало ускорение в 12 раз. Как это удалось сделать? Пришлось сделать модель менее точной за счет добавления предположений и упрощения исходной задачи, чтобы использовать дерево поиска. Еще он оптимизировал сам алгоритм, обрабатывая некоторые краевые случаи отдельно.
Вишенкой стало переписывание на ассемблер одной функции, время выполнение которой занимало 98% от времени работы программы, а также покупка более производительного оборудования и изменение разрядности чисел с 64 бит на 32 бита.
В книжке эти данные собрали в таблицу, из которой станет понятно, что правильный алгоритм и подходящая структура данных дали бОльшую часть выигрыша производительности. Но ему пришлось делать свою модель менее точной, но зато работающей не года, а всего лишь 1 день.
Это еще один урок, и он не только про алгоритмы и структуры данных, но и про то, что разработка программного обеспечения это всегда компромиссы ("trade-off", его чаще используют в сленге) и программные системы - это не сферический конь в вакууме, а что-то работающее в реальном мире.
Получается, что алгоритмы все же нужны?
@it_intern
#алгоритмы #книгиRaft.
Мы говорили про проблему консенсуса и кворума. Для решения задач консенсуса существует несколько алгоритмов и подходов. Наверное, самый используемый алгоритм сейчас - это Raft.
Raft решает задачу консенсуса в распределенных системах в ненадежных коммуникационных сетях. Он разрабатывался на основе опыта более старого алгоритма Paxos (также его называют семейством протоколов). Raft получился более простым теоретически и в реализации. Существует множество реализаций Raft с открытым исходным кодом на разных языках программирования.
Paxos действительно сложный алгоритм. Признаюсь, что я не до конца его понимаю. Наверное, потому что я с ним не работал в проде. Сейчас я искал хорошую и простую визуализацию этого алгоритма и не нашел ее. Есть только заумные и сложные научные статьи. Поэтому я не очень хотел писать про этот алгоритм, но это нужно для понимания откуда произошел Raft. Если вы хотите разобраться с Paxos, то вот неплохие статьи - раз и два.
http://thesecretlivesofdata.com/raft/
А вот про Raft хороших статей много и есть даже прекрасный эксплейнер. На этом ресурсе еще раз рассказывают про проблему распределенного консенсуса и кворума, про типы узлов кластера в терминах Raft, процесс выбора лидера (leader election), и самое важное про то как действует алгоритм при проблемах с сетями.
Понимание Raft дает человеку основное представление о проблемах, возникающих в распределенных системах и о том, как их можно решить. Про Raft меня спрашивали несколько раз на собеседованиях на уровень Senior, но узнать про него раньше точно никому не помешает 😉
Успехов!
@it_intern
#архитектура #распределенные_системы
//АйТи интерн
Quorum. В прошлый раз мы говорили о проблеме Split-brain’а. Она происходит, когда распределенная система разделяется на несколько частей. Ее можно решить с помощью Quorum и Fencing. ”Quorum praesentia sufficit - установленное законом, уставом организации или регламентом число участников собрания (заседания), достаточное для признания данного собрания правомочным принимать решения по вопросам его повестки дня.” Это определение не из информатики, но верно передающее суть происходящего в распределенных системах (удивительно!). Кворум - это минимальное количество голосов от узлов системы для фиксации выполнения какого-нибудь действия в распределенной системе, требующего согласования. Обычно это запись данных внутрь системы или обновление состояние самой системы. Кворумы - это часть более глобальной проблемы, решение которой обеспечивает согласованность данных в распределенных системах. Эта проблема - консенсуса. Алгоритм консенсуса — это процесс, используемый для достижения согласия по одному значению данных…
Raft.
Мы говорили про проблему консенсуса и кворума. Для решения задач консенсуса существует несколько алгоритмов и подходов. Наверное, самый используемый алгоритм сейчас - это Raft.
Raft решает задачу консенсуса в распределенных системах в ненадежных коммуникационных сетях. Он разрабатывался на основе опыта более старого алгоритма Paxos (также его называют семейством протоколов). Raft получился более простым теоретически и в реализации. Существует множество реализаций Raft с открытым исходным кодом на разных языках программирования.
Paxos действительно сложный алгоритм. Признаюсь, что я не до конца его понимаю. Наверное, потому что я с ним не работал в проде. Сейчас я искал хорошую и простую визуализацию этого алгоритма и не нашел ее. Есть только заумные и сложные научные статьи. Поэтому я не очень хотел писать про этот алгоритм, но это нужно для понимания откуда произошел Raft. Если вы хотите разобраться с Paxos, то вот неплохие статьи - раз и два.
А вот про Raft хороших статей много и есть даже прекрасный эксплейнер. На этом ресурсе еще раз рассказывают про проблему распределенного консенсуса и кворума, про типы узлов кластера в терминах Raft, процесс выбора лидера (leader election), и самое важное про то как действует алгоритм при проблемах с сетями.
Понимание Raft дает человеку основное представление о проблемах, возникающих в распределенных системах и о том, как их можно решить. Про Raft меня спрашивали несколько раз на собеседованиях на уровень Senior, но узнать про него раньше точно никому не помешает 😉
Успехов!
@it_intern
#архитектура #распределенные_системы
//АйТи интерн
Quorum. В прошлый раз мы говорили о проблеме Split-brain’а. Она происходит, когда распределенная система разделяется на несколько частей. Ее можно решить с помощью Quorum и Fencing. ”Quorum praesentia sufficit - установленное законом, уставом организации или регламентом число участников собрания (заседания), достаточное для признания данного собрания правомочным принимать решения по вопросам его повестки дня.” Это определение не из информатики, но верно передающее суть происходящего в распределенных системах (удивительно!). Кворум - это минимальное количество голосов от узлов системы для фиксации выполнения какого-нибудь действия в распределенной системе, требующего согласования. Обычно это запись данных внутрь системы или обновление состояние самой системы. Кворумы - это часть более глобальной проблемы, решение которой обеспечивает согласованность данных в распределенных системах. Эта проблема - консенсуса. Алгоритм консенсуса — это процесс, используемый для достижения согласия по одному значению данных…
Fencing (не Fendi).
Fencing — один из способов решения проблемы Split Brain’а и обеспечения High Availability в распределенных системах. В прошлый раз мы рассматривали кворумы и проблему консенсуса (к ней еще вернемся).
Во время эксплуатации распределенной системы возникает ситуация, когда один из узлов системы начинает вести себя “странно” - не отвечать на запросы, рассылать неверную информацию, передавать состояние, которое не может быть у этого узла, и т.д.
Для избежания дальнейших проблем с общими ресурсами кластера, система изолирует этот узел, делая для него fence (русск. заграждающая метка).
То есть когда мы делаем fencing (пунктир на картинке) для узла “C”, то на вопрос: “будет ли узел “C” отвечать за ресурс X или на вопрос Y?”, - мы всегда будем получать ответ: “НЕТ!”. Таким образом нам не нужно беспокоиться о том в каком состоянии узел “А”.
Для выполнения fencing существуют 2 основных техники:
- fencing ресурсов - изоляция ресурса, который использует или владеет неработающий корректно узел. Например, отзыв доступа к сетевому хранилищу данных с этого узла.
- node fencing - изоляция всего узла от всех ресурсов, не разбирая какие ресурсы, он в действительности использует. Грубо и жестко. Это также называют “STONITH” - Shoot The Other Node In The Head.
С помощью fencing мы можем изолировать проблемные узлы кластера, не мешая основной работе системы. Fencing считается хорошей техникой для организации безопасного и предсказуемого доступа к общим ресурсам и предотвращения ошибок в данных.
Во взрослом мире промышленного программирования fencing недостаточен для эксплуатации распределенных систем. Есть сценарии и ошибки, когда разработчикам приходится использовать другие техники или их комбинации. Часть из них мы рассмотрели, а другая часть требует детального погружения в распределенные системы.
Дальше поговорим про алгоритмы консенсуса. Их могут спросить на собесах, да и полезно их знать.
Успехов!
@it_intern
#архитектура #распределенные_системы
Quorum.
В прошлый раз мы говорили о проблеме Split-brain’а. Она происходит, когда распределенная система разделяется на несколько частей. Ее можно решить с помощью Quorum и Fencing.
”Quorum praesentia sufficit - установленное законом, уставом организации или регламентом число участников собрания (заседания), достаточное для признания данного собрания правомочным принимать решения по вопросам его повестки дня.”
Это определение не из информатики, но верно передающее суть происходящего в распределенных системах (удивительно!). Кворум - это минимальное количество голосов от узлов системы для фиксации выполнения какого-нибудь действия в распределенной системе, требующего согласования. Обычно это запись данных внутрь системы или обновление состояние самой системы.
Кворумы - это часть более глобальной проблемы, решение которой обеспечивает согласованность данных в распределенных системах. Эта проблема - консенсуса.
Алгоритм консенсуса — это процесс, используемый для достижения согласия по одному значению данных, предложенное одним из узлов распределенной системы. Например, пользователь записал данные в систему, а узлы системы должны прийти к консенсусу и записать это значение. Проблема при выполнении этого в распределенной системе заключается в том, что сообщения могут быть потеряны или узлы могут выйти из строя.
Узлы не придут к консенсусу, если отказов узлов в системе больше половины. Это число связано с кворумами, т.к. почти любой шаг алгоритмов консенсуса считается завершенным, только когда есть кворум. Если отказов узлов больше половины, то кворум не соберется, и система скорее всего не будет отвечать клиенту. Но этот момент зависит от алгоритмов консенсуса, от выбранных моделей консистентности данных, ну и конечно от бизнес требований.
Если есть кворум, т.е. большинство голосов, то распределенная система может сохранять новые входящие данные даже при разделении ее на части. Поэтому в распределенных системах делают нечетное количество узлов (3, 5, 7), чтобы избежать разделение кластера на несколько частей с одинаковым числом узлов.
Но и это может не гарантировать наличие кворума и консенсуса 🙂 Вот такие они распределенные системы.
Успехов!
@it_intern
#архитектура #распределенные_системы
Quorum.
В прошлый раз мы говорили о проблеме Split-brain’а. Она происходит, когда распределенная система разделяется на несколько частей. Ее можно решить с помощью Quorum и Fencing.
”Quorum praesentia sufficit - установленное законом, уставом организации или регламентом число участников собрания (заседания), достаточное для признания данного собрания правомочным принимать решения по вопросам его повестки дня.”
Это определение не из информатики, но верно передающее суть происходящего в распределенных системах (удивительно!). Кворум - это минимальное количество голосов от узлов системы для фиксации выполнения какого-нибудь действия в распределенной системе, требующего согласования. Обычно это запись данных внутрь системы или обновление состояние самой системы.
Кворумы - это часть более глобальной проблемы, решение которой обеспечивает согласованность данных в распределенных системах. Эта проблема - консенсуса.
Алгоритм консенсуса — это процесс, используемый для достижения согласия по одному значению данных, предложенное одним из узлов распределенной системы. Например, пользователь записал данные в систему, а узлы системы должны прийти к консенсусу и записать это значение. Проблема при выполнении этого в распределенной системе заключается в том, что сообщения могут быть потеряны или узлы могут выйти из строя.
Узлы не придут к консенсусу, если отказов узлов в системе больше половины. Это число связано с кворумами, т.к. почти любой шаг алгоритмов консенсуса считается завершенным, только когда есть кворум. Если отказов узлов больше половины, то кворум не соберется, и система скорее всего не будет отвечать клиенту. Но этот момент зависит от алгоритмов консенсуса, от выбранных моделей консистентности данных, ну и конечно от бизнес требований.
Если есть кворум, т.е. большинство голосов, то распределенная система может сохранять новые входящие данные даже при разделении ее на части. Поэтому в распределенных системах делают нечетное количество узлов (3, 5, 7), чтобы избежать разделение кластера на несколько частей с одинаковым числом узлов.
Но и это может не гарантировать наличие кворума и консенсуса 🙂 Вот такие они распределенные системы.
Успехов!
@it_intern
#архитектура #распределенные_системы
Photo unavailableShow in Telegram
Кабанчик.
Меня спросили про "кабанчика". Кабанчик - это на программистком сленге название книги “Designing Data-Intensive Applications” от Мартина Клеппмана.
Она действительно стала легендарной. Я думаю, что она качественно улучшила и систематизировала знания об архитектуре современных разработчиков. Компании рекомендуют эту книгу для подготовки к архитектурным секциям или указывают ее в обратной связи после собесов.
Ее автор - Мартин Клеппман, ученый-информатик. Работает и читает лекции в Кембриджском университете, исследует распределенные системы. Также он у него есть аккаунт на Патреоне с большим количеством спонсоров.
Несколько лет назад я мог посетить конференцию с его участием и лично. У меня был доступ к спикерской зоне, но я поленился ехать, потом началась корона ;(
Не упускайте возможности!
#архитектура #распределенные_системы #книги
Кабанчик.
Меня спросили про "кабанчика". Кабанчик - это на программистком сленге название книги “Designing Data-Intensive Applications” от Мартина Клеппмана.
Она действительно стала легендарной. Я думаю, что она качественно улучшила и систематизировала знания об архитектуре современных разработчиков. Компании рекомендуют эту книгу для подготовки к архитектурным секциям или указывают ее в обратной связи после собесов.
Ее автор - Мартин Клеппман, ученый-информатик. Работает и читает лекции в Кембриджском университете, исследует распределенные системы. Также он у него есть аккаунт на Патреоне с большим количеством спонсоров.
Несколько лет назад я мог посетить конференцию с его участием и лично. У меня был доступ к спикерской зоне, но я поленился ехать, потом началась корона 🙁
Не упускайте возможности!
#архитектура #распределенные_системы #книги
Choose a Different Plan
Your current plan allows analytics for only 5 channels. To get more, please choose a different plan.