Для любого разработчика глубокое понимание основных принципов системного проектирования является необходимым условием для создания стабильных и масштабируемых программных систем, способных обеспечивать высокую производительность. Системное проектирование (System Design) включает разработку архитектуры и структуры программной системы, направленную на удовлетворение специфических требований и обеспечение требуемых показателей производительности.

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

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

Как и было обещано, в завершение серии ( 1 • 2 • 3 • 4 • 5 ) статей о разработке инструмента для ETL больших данных, я выкладываю выжимку ответов на вопросы.

А то статьи были в формате туториала для разработчиков таких инструментов (длинные и с высоким уровнем сложности), так что стоит рассказать более кратко и понятно для каждого.

Q. Что это такое?

A. Специализированный инструмент для а) быстрого создания ETL процессов и б) эффективного по стоимости их выполнения.

Промка: https://dcetl.ru
Исходники: https://github.com/PastorGL/datacooker-etl
Официальная группа в телеге: https://t.me/data_cooker_etl

В предыдущих сериях (FAQ • 1 • 2 • 3 • 4 • 5 ) мы весьма подробно рассмотрели, как написать на Java собственный интерпретатор объектно-ориентированного диалекта SQL поверх Spark RDD API, заточенный на задачи подготовки и трансформации наборов данных.

В данной части поговорим о том, как добавить в выражения SQL поддержку функций. Например,

SELECT
    MAX(score1, score2, score3, score4, score5) AS max_score,
    MIN(score1, score2, score3, score4, score5) AS min_score,
    MEDIAN(score1, score2, score3, score4, score5) AS median_score,
    score1 + score2 + score3 + score4 + score5 AS score_sum
FROM raw_scores INTO final_scores
WHERE ABS(score1 + score2 + score3 + score4 + score5) > $score_margin;

— тут у нас функции MAX, MIN и MEDIAN принимают любое количество аргументов типа Double и возвращают Double, а ABS только один такой аргумент.

Вообще, кроме общей математики, в любом уважающем себя диалекте SQL как минимум должны быть функции для манипуляций с датой/временем, работы со строками и массивами. Их мы тоже обязательно добавим. В classpath, чтобы движок мог их оттуда подгружать. До кучи, ещё и операторы типа >= или LIKE, которые у нас уже были реализованы, но хардкодом, сделаем такими же подключаемыми.

Здравствуйте, дорогие хабровчане. Сегодняшняя статья — результат моего небольшого исследования. Я хочу показать, как компилировать бинарные модули расширения (.so) из python-файлов, чем они будут отличаться и как с ними работать. Делать это мы будем при помощи компилятора Nuitka. Он наиболее известен тем, что с его помощью можно создавать исполняемые файлы (.exe) для Windows. Однако, кроме того, он позволяет создавать и бинарные модули python. Всех, кому это интересно, прошу под кат.

Объём специфичных знаний, которые требуются рядовому программисту игр, даже если он только начал свою карьеру, вызывает у меня «лёгкую» тоску. Это одна из причин, почему большая часть людей, которые «горят делать игры», отсеивается на этапе технических собеседований (обычно их больше одного). Это нормально и грустно. Добавьте сюда, что нефундаментальные знания, вроде инструментов, библиотек и движков, приходится обновлять где‑то раз в 5–7 лет. Не вижу тут, что игрострой сильно отличается от других областей разработки. Если бы лет 15 назад «добрый я» скинул на почту список книг, которые придется прочитать и осмыслить, армия собранных граблей не была бы столь большой и разнообразной, и без ручек половинной длины. Осторожно, в конце статьи будет супердлинная картинка (взята с github отсюда, с разрешения автора).

Выбор видеокарты — дело личное. Кому-то нравятся бренды, кто-то хочет сэкономить. Некоторым нравится, чтобы видюха светилась. Мы сегодня расскажем, какие видеокарты есть в наличии в разных ценовых категориях. И если вы ищете себе GPU или хотите посоветовать что-то друзьям, под катом — разбор актуального ассортимента XCOM-SHOP.

Какое-то время назад, во время разбора кода, мы обсудили выбор dict() вместо {} в новом коде на Python. Коллега утверждал, что dict() более читаем и чётче выражает цель, поэтому следует предпочесть его. Меня это не убедило, но в тот момент контраргуентов не нашлось, поэтому я воздержался.

Это заставило меня задуматься: в чём разница между типом dict и литеральным выражением {}?

Давайте изучим этот вопрос.

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

В новых версиях Python аннотации типов получают всё большую поддержку, всё чаще и чаще используются в библиотеках, фреймворках, и проектах на Python. Помимо дополнительной документированности кода, аннотации типов позволяют таким инструментам, как mypy, статически произвести дополнительные проверки корректности программы и выявить возможные ошибки в коде. В этой статье пойдет речь об одной, как мне кажется, интересной теме, касающейся статической проверки типов в Python – протоколах, или как сказано в PEP-544, статической утиной типизации.

В Python 3.8. появилась новая примечательная возможность — протоколы (protocols). Протоколы — это альтернатива абстрактным базовым классам (abstract base classes, ABC). Они позволяют пользоваться структурной подтипизацией (structural subtyping), то есть — осуществлять проверку совместимости классов исключительно на основе анализа их атрибутов и методов. В этом материале мы поговорим о протоколах в Python и разберём практические примеры работы с ними.

Многие проекты на Django начинаются просто: есть база данных и к приложению, которое крутится на сервере, идут обращения. Например, так начиналась Dodo IS (информационная система компании Додо Пицца, где работал автор сегодняшней статьи). Но если использовать Django из коробки, можно натворить много бед и встретить пачку антипаттернов. Возможно, вы встречали такое на старых legacy-проектах.

Евгений Пешков развивает сообщество DDD-практиков, рассказывая, какие проблемы решает Domain-Driven Design (предметно-ориентированное проектирование) в современном мире. На конференции Russian Python Week 2020 он выступил с рассказом об этом. Кстати, 19 августа пройдет встреча DDDevotion-сообщества, присоединяйтесь, будем о чем поговорить.

В сегодняшней статье будет его рассказ про то, как устроен Domain-Driven Design и какие инструменты использует, чтобы наиболее точно описать требования бизнеса и сам бизнес.

Привет.

Я впервые пишу в поток об управлении и найме персонала. Речь пойдет об одном из способов классифицировать ваших будущих или действующих программистов. Мой основной тезис: все разработчики, грубо говоря, делятся на 4 больших типажа и каждому из этих типажей есть своя область применения. Попытка направить неправильный типаж на решение неподходящих для него задач ведет к провалу (неэффективная работа, или сотрудник покидает команду). Хотите знать почему так — добро пожаловать под кат. Приготовьтесь, текста много.

При выполнении параллельной программы, активно задействующей CPU, нам часто необходимо, чтобы пул потоков или процессов имел размер, сопоставимый с количеством ядер CPU на машине. Если потоков меньше, то вы будете использовать все преимущества ядер, если меньше, то программа начнёт работать медленнее, так как несколько потоков будет конкурировать за одно ядро. Ну, или такова ситуация в теории.

Как же проверить, сколько ядер есть у компьютера? И действительно ли это хороший совет?

Оказывается, на удивление сложно определить, сколько потоков выполнять:

- В стандартной библиотеке Python есть множество API для получения этой информации, но ни одного из них недостаточно.

- Хуже того, из-за таких функций CPU, как параллельность на уровне команд и одновременной многопоточности (Hyper-threading в CPU Intel), количество ядер, которое можно эффективно использовать, зависит от того кода, который напишете вы!

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

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

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

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

В этой статье мы с вами разберемся, как использовать корутины в Kotlin.

Все мы думаем, что хорошо говорим и пишем на своём родном русском языке. Не зря же в конце концов мы столько учились, да и в деловой переписке у нас всё вроде бы вполне неплохо. Но знаете ли вы о том, что даже для написания IT-документации есть свои правила? Поэтому сегодня в блоге ЛАНИТ на Хабре мы поделимся знаниями о русском «документном» языке. 

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

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