О сложных системах простыми словами.

В шпаргалке на высоком уровне рассматриваются такие вещи, как протоколы коммуникации, DevOps, CI/CD, архитектурные паттерны, базы данных, кэширование, микросервисы (и монолиты), платежные системы, Git, облачные сервисы etc. Особую ценность представляют диаграммы — рекомендую уделить им пристальное внимание. Полагаю, шпаргалка будет интересна всем, кто хоть как-то связан с разработкой программного обеспечения и, прежде всего, веб-приложений. Буду признателен за помощь в уточнении/исправлении понятий, терминологии, логики/алгоритмов работы систем (в рамках того, что по этому поводу содержится в оригинале), а также в обнаружении очепяток.

Выражаю благодарность Анне Неустроевой за помощь в редактировании материала.

Возможно, немного другой формат шпаргалки покажется вам более удобным.

System Design (сборник на английском языке).

Модель памяти представляет из себя спецификацию допустимого поведения многопоточных программ, работающих с разделяемой памятью (shared memory) [1]. Наиболее примитивной моделью является последовательная согласованность (sequential consistency), где все инструкции из всех потоков образуют общий порядок (или, по крайней мере, его видимость), согласованный с порядком выполнения программы в каждом потоке [2].

Одной из наиболее важных фич C++11 является модель памяти, поддерживающая параллелизм, которая позволяет писать многопоточные программы, не полагаясь на различные расширения для конкретных целевых платформ.

В данной статье я опишу свой опыт создания Face ID для входной двери.

Для реализации данной идеи у меня уже было:

• Умный дом на базе homeassistant (необязательно)

• MQTT сервер

• Умный замок

• Камера с возможностью забирать с неe фото

В прошлых частях мы рассмотрели семейство квантовых гейтов: Инвертор, C-NOT, Адамара, инверсия фазы. Но, согласитесь, как-то не похожи они на привычные нам гейты классических компьютеров: AND, OR, XOR, NOT. Ну, ладно, с NOT это я хватил лишку, NOT это вполне тоже самое, что квантовый инвертор, который мы рассмотрели самым первым гейтом в прошлых частях.

А как быть с остальными? Можем ли мы как-то сделать, к примеру, квантовый AND?
И да, и нет. Как вы помните из второй части, квантовая операция обязана обладать двумя важными свойствами:

• свойство обратимости, которое мы рассматривали, что если применить операцию к квантовому регистру повторно, то регистр вернется в исходное состояние.

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

Как вы, может, помните с первым свойством я в прошлых частях приврал. На самом деле, свойство обратимости заключается в том, что для каждой квантовой операции существует обратная квантовая операция, которую можно вычислить из исходной определенными математическими действиями. Нам просто до сих пор везло, что обратные операции для гейтов Адамара, инвертора, C-NOT и инверсии фазы являлись теми же самыми операциями. Поэтому я и приврал тогда, что обратимость операции, примененная дважды возвращает в исходное состояние. Нет, забудьте, это неправда. Теперь обратимость сформулируем следующим образом.

Я подустал от мрачных текстов и вспомнил о своей давней мечте. За 20 с хвостиком лет работы в Интел у меня развеселых историй накопилось на целую книгу. Хотелось в ретроспективе посмотреть на некоторые события, участником которых мне довелось быть. И еще хотелось отдать дань уважения компании и людям, с которыми мне посчастливилось работать. Я уже даже название придумал – Made at Intel. Понятно, что пока я был внутри конторы, речь о публикации этих баек идти не могла. Я сам подшучивал, что для публикации нужно правильно выбрать время. В смысле сначала уволиться, а потом публиковать, а не быть уволенным вследствие публикации. :) Однако примерно 2 года назад я Интел покинул, и казалось бы меня уже ничего не сдерживало. Но тут, как всегда – то перо поломается, то струна порвется, то еще какая бяда приключится. К тому же на то чтобы писать книжку – это же рeшимости набраться надо... И вот – вчера я решил, что большое надо начинать с малого. Буду писать по главке и выкладывать сюда - собирать фидбек. Так мало –помалу и наберется.

Итак, сегодня вашему вниманию представляется первая глава, в которой эволюция архитектур Intel рассматривается с точки зрения ... истории религиозных течений. Да –да, не удивляйтесь, архитектура вычислительных устройств –это одна из самых религиозных вещей. Не думайте, что все решения по Instruction Set Architecture принимаются исключительно на основе анализа данных – это совсем не так. Скорее похоже на средневековое государство – тут есть немного бизнеса, побольше политики и очень много религии. Все просто – почти любой эксперимент в этой области растягивается на годы и обходится в миллиарды долларов. Хуже всего, что в процессе дизайна можно давать лишь приблизительные оценки ключевых характеристик – частоты, производительности, энергопотребления, температурной карты. То, как все оно будет на самом деле становится понятным уже только тогда, когда чип выходит из печки. Да сейчас в этой области уже накоплен определенный опыт и наши оценки становятся несколько точнее, но и только. А 20 лет назад этих знаний было куда меньше. И пионеры, подобные Интел двигались в темноте на собственный страх и риск. Разумеется, в таких условиях на первый план выходит кто во что ВЕРИТ. Ну да – еще кто лучше говорить умеет. Поэтому лучшие архитекторы приходят из школ с углубленным изучением богословия. :)

Есть бесконечное количество способов ошибиться при написании кода. Однако иногда можно заметить явные интересные закономерности, как и где ошибаются программисты. Поговорим о коде, который "притягивает" опечатки.

На чём основаны наблюдения

С целью тестирования и продвижения статического анализатора кода PVS-Studio мы проверяем различные открытые проекты. Найдя ошибки, мы сообщаем о них авторам проектов, коллекционируем их и пишем статьи про наиболее интересные случаи.

Рассматривая все эти ошибки, я постепенно замечаю различные повторяющиеся паттерны опечаток. За редким исключением они не зависят от языка программирования. По крайней мере, они одновременно свойственны коду, написанному на C, C++, C#, Java. В этой статье я опишу 7 паттернов, которые заметил к настоящему моменту:

1. Эффект последней строки.
2. Злополучная функция memset.
3. Неверные функции сравнения.
4. Неверные функции копирования.
5. Ошибки работы с датами и временем.
6. Несчастливые числа: 0, 1, 2.
7. Ошибка на единицу (off-by-one error).

Заметность закономерностей в ошибках свидетельствует о том, что они крайне распространены. Полезно знать о них, чтобы избегать написания потенциально опасного кода или более эффективно находить их в процессе обзоров кода. Другим словами, вы узнаете, какой код притягивает ошибки, и будете более внимательно его проверять. Конечно, PVS-Studio способен выявить многие подобные ошибки, но не все. Поэтому дополнительное внимание не повредит.

Почему люди выгорают, как отличить выгорание от усталости, как отловить на ранних стадиях, терминология и нейробиология процесса на пальцах. Первая статья цикла — вводная: разбираемся с терминами и пониманием явления.

Вводная часть

Выгорание — довольно объемная тема, охватить которую в рамках одной статьи не вижу возможности. Воспринимать такой объем информации, утрамбованный в одну статью, будет сложновато.

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

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

Квантовые компьютеры. С точки зрения традиционного программиста-математика.
Часть 1. Основы. Квантовый регистр.

О чем эта публикация

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

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

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

Привет! На связи команда «БАРС Груп». Мы разработали и совершенствуем российскую BI‑платформу Alpha BI. Это возможно благодаря таким фреймворкам, как PyTorch.

PyTorch активно развивается более пяти лет и представляет собой целую экосистему для создания моделей машинного обучения на основе глубоких нейронных сетей. У подобных ИТ‑продуктов широкий спектр применения. В частности, они помогают научному и бизнес‑сообществу проводить исследования, вести разведку данных и проверять гипотезы. Несмотря на то, что на сегодняшний день это один из самых популярных фреймворков машинного обучения в мире, в рунете пока довольно мало статей о его технических особенностях. Попытаемся это исправить.

Привет, Хабр! В этой статье я расскажу всё, что знаю про Entity-Component-System и попытаюсь развеять различные предубеждения об этом подходе. Здесь вы найдете много слов о преимуществах и недостатках ECS, об особенностях этого подхода, о том как с ним подружиться, о потенциальных граблях, о полезных практиках, а также в отдельном разделе коротко посмотрим на ECS фреймворки для Unity/C#.

Современная теория хаоса — это большая и хорошо разработанная область математики, уже прочно вошедшая в набор современных инструментов естествознания. Многие результаты теории динамического хаоса, такие как странные аттракторы, бифуркационные диаграммы, фрактальные области притяжения, разобраны популяризаторами математики на плакаты, мемы и открытки. В этой мини‑серии статей я хочу копнуть немного глубже стандартных введений и «альбомов» с симпатичными картинками и дать пример разбора одной несложной, но ещё не «заезженной» механической системы, которая демонстрирует механизмы возникновения хаоса в гамильтоновых системах.

Предупреждаю, в тексте достаточно много анимированных картинок и не очень много практической пользы :)

Откуда берëтся динамический хаос в простейших механических системах? Как его изучать? А это настоящий хаос или просто что-то очень сложное?

Я начинаю мини-серию статей, в которой мы будем понемногу знакомиться с элементами теории хаоса. За последние полвека сформировался набор классических примеров, кочующих из одного популярного введения в другое: аттрактор Лоренца, логистическое уравнение, двойной маятник, подкова Смэйла и т.п. Я, конечно, их упомяну, но мне бы хотелось показать что, кроме классики, есть хаотические системы, обойдённые вниманием, но, тем не менее, имеющие малую размерность и вполне ясные физические модели, при этом способные порождать красивые и сложные, примеры хаотического поведения, поддающиеся объяснению.

Это пример небольшого исследования, доступного студентам младших курсов, поэтому я позволю себе привести некоторые подробности анализа, которые искушённому читателю могут показаться излишними. Моя задача показать, что даже очень простые системы могут быть очень интересными, красивыми и доступными для глубокого анализа. И, конечно же, это повод показать симпатичные картинки, как правило, фрактальные. Ведь все же любят фракталы, верно? Ну, поехали!

Конвейер трудится изо всех сил, чтобы повысить производительность твоей программы. А злобные «if»'ы нагло врываются посреди его работы и всё портят!

На сколько полезен конвейер в современных ЭВМ? Как сильно мешаются ветвления в коде, которые ты написал? И как архитекторы процессоров сглаживают ущерб, который «if»'ы наносят по производительности программ?