Инженер-программист
Для любого разработчика глубокое понимание основных принципов системного проектирования является необходимым условием для создания стабильных и масштабируемых программных систем, способных обеспечивать высокую производительность. Системное проектирование (System Design) включает разработку архитектуры и структуры программной системы, направленную на удовлетворение специфических требований и обеспечение требуемых показателей производительности.
С учетом стремительного прогресса в области технологий и возрастающей сложности программных приложений, овладение принципами системного проектирования становится критически важным для разработчиков, стремящихся создавать эффективные системы. Не имеет значения новичок вы или опытный специалист: освоение этих принципов позволит вам разрабатывать надежные и масштабируемые программные системы, отвечающие требованиям современных приложений.
Далее мы рассмотрим каждый из принципов более детально, чтобы понять их суть и способы применения в разработке приложений.
В комментариях к моей предыдущей статье и в комментариях к ролику было много вопросов и некорректных замечаний по поводу парадокса близнецов. Как оказалось, мое объяснение оказалось не настолько понятным, как я надеялся, поэтому в этой статье я решил максимально наглядно, подробно и последовательно объяснить парадокс близнецов и ответить на некоторые другие вопросы.
Кратко напомню суть парадокса
Берем двух близнецов, сажаем их на маленькую легкую планету (легкую, чтобы не учитывать влияние гравитации), одного оставляем неподвижным, а второго запускаем на ракете полетать и вернуться обратно. При их встрече оказывается, что летавший близнец постарел меньше, чем неподвижный.
Парадокс заключается в том, что неочевидно почему именно у летавшего время текло медленнее. Ведь, вроде бы, ситуация симметричная: в системе отсчета летавшего он был неподвижен, а планета с неподвижным близнецом полетала и вернулась, и это у них должно было натикать меньше времени.
Парадокс близнецов очень важен, т.к. это самый наглядный способ увидеть, что релятивистский эффект замедления времени не просто математический артефакт специальной теории относительности или иллюзия, а вполне реальное физическое явление.
Попросим бегущего кота четыре секунды (по его часам) бежать вправо со скоростью 75% скорости света, потом развернуться и прибежать с той же скоростью назад.
Вот визуализация на диаграмме.
display: flex;
justify-content: center; /* Горизонтальное центрирование */
align-items: center; /* Вертикальное центрирование */display: grid;
justify-items: center; /* Горизонтальное центрирование */
align-items: center; /* Вертикальное центрирование */justify-content стало justify-items.
Всем привет! Я Сергей, работаю в B2B-команде Яндекс Маркета последние 3,5 года. Как уже понятно из заголовка, сейчас я вам расскажу про yet-another-миграцию с базы на базу, которая началась в середине 2021 года и заняла почти год. Получается, мемуары.
Вас ждёт рассказ о том, как мы:
- несколько месяцев чинили тесты и делали трансформер;
- десятки раз переливали данные;
- чинили баги незаметно для пользователей;
- заставили сервис работать на PostgreSQL быстрее, чем он работал на Oracle.
Давно удивлялся, почему не смотря на распространенность счетчиков Меркурий и возможность съема с них показаний через RS-485, на рынке DIY устройств не было Zigbee шлюза для них. Этот пробел я решил восполнить самостоятельно.
В этой статье мы рассмотрим использование DiagnosticListener для изоляции кода, отвечающего за логгирование инфраструктурных операций - таких как работа с базой данных и отправка и получение HTTP запросов.
Класс DiagnosticListener определен в пакете System.Diagnostics, и особенности его использования описаны в разных статьях, включая одну-две на Хабре.
В этой статье будут кратко рассмотрены способы подписки и использования диагностических событий, а также как можно обойти основные ограничения, присущие текущей реализации DiagnosticListener, и сделать использование этого функционала более эффективным.
Всем привет, меня зовут Артемий, я работаю старшим Android-разработчиком в команде пользовательского профиля в RuStore. Мой опыт в индустрии уже 8 лет. За это время я успел поработать в разных проектах и компаниях. У меня был опыт работы в проекте, в котором было свыше 300 модулей и больше 60 Android-разработчиков. Такие условия заставляют задуматься о масштабируемости на принципиально ином уровне.
Сегодня я расскажу о способах обеспечения масштабируемости проекта и как этому может навредить неправильное восприятие Чистой Архитектуры (далее — ЧА). Предупреждаю сразу, это лонгрид в двух частях!
В прошлых двух частях мы ознакомились с синтаксической моделью F#-кода и с инструментами для неё. Объёмный пример туда уже не влез, но необходимость в нём осталась. Так родились ещё две заключительные части цикла. Их объединяет общий проект, но в остальном они представляют собой сборную солянку фактов, практик и наблюдений, которые было бы трудно разместить в каталогизированной документации.
Мы возьмём сугубо игровую задачу с понятным результатом и на её примере узнаем:
• на какие ноды AST стоит обратить внимание в первую очередь;
• где Fantomas-у нельзя доверять;
• где можно хакать;
• где лучше придерживаться пуризма;
• и как на F# можно строить Fluent API.
В этой части мы сосредоточимся на общей организации генератора, входных данных и основных элементах AST. В следующей сделаем то же самое, но на более сложном уровне, сместив повествование в сторону устройства Fluent API.
С течением времени мир вокруг нас все больше усложняется, а количество способов измерения этой самой сложности растет еще быстрее. Существует мнение, что увеличение количества метрик может указывать на некоторую степень путаницы в области сложных систем. В сущности, многие метрики сложности представляют собой различные вариации нескольких базисных идей. В этой статье вашему вниманию представлены (неполное) перечисление и категоризация метрик сложности.
«ООП для меня означает лишь обмен сообщениями, локальные ограничения и защиту, сокрытие состояния процесса и крайне позднее привязывание», — Алан Кэй (человек, придумавший термин «объектно-ориентированное программирование»)1
Не так давно в одной из статей я уже касался темы, краешком связанной с Манхэттенским проектом, и этот материал также имеет к нему некоторое отношение. Более того, учитывая масштаб и количество участников проекта, я наверняка буду его упоминать и в некоторых последующих текстах. Эта статья написана на основе исследования американского разработчика программного обеспечения Пола Релкина.
Итак, Лос-Аламос объединил одной целью многих видных учёных того времени. Одним из них был замечательный учёный Ричард Фейнман. Разумеется, основным предметом его интереса всегда была физика, но помимо потрясающих познаний в ней, профессор Фейнман отличался и другими талантами. Из его автобиографии (всем, кто ещё не читал, настоятельно рекомендую) известен факт, что профессор особенно гордился своими реактивными скилами решения головоломок и математических задач.
Всем привет!
Все мы постоянно используем Chrome DevTools, но там так много фичей, что некоторые из них мы никогда не использовали и даже не замечали. В этой небольшой статье, я хочу поделиться интересными находками, которыми пользуюсь сам.
Возможно вы уже видели эти фичи и используете их на постоянной основе, а возможно это именно те фичи, которых вам так давно не хватало в вашей работе.
Погнали!