Чистый код не набор внешних признаков, таких как наименование переменных и наличие или отсутствие комментариев, хотя они тоже важны. Чистый код — это архитектура программного продукта, которая позволяет легко читать и модифицировать программный код. Написание такого кода опирается на множество типовых шаблонов (SOLID, паттрерны проектирования и др.), выработанных в ходе практики программирования. Описание еще одного такого шаблона приведено в этой статье.

Неизменяемым называется объект (англ. immutable object), состояние которого не может быть изменено после создания⁽¹⁾. Это понятие не так широко используется в различной литературе, поэтому начну с более подробного разбора этого понятия и обоснования, почему стоит применять этот шаблон.

Классическое определение гласит - Объектно ориентированное программирование (ООП), парадигма программирования, в рамках которой программа представляется в виде совокупности объектов, а её выполнение состоит во взаимодействии между объектами. Объектом называется набор из данных и операций, которые можно выполнить над этими данными⁽²⁾.

Практика программирования показывает, что не все операции которые можно выполнить над данными стоит помещать в один объект. Например, формулу расчет угла в прямоугольном треугольнике можно представить как константное выражение. Вероятность её изменения приближается к нулю, поэтому ее можно смело применять как часть объекта с данными. Другой пример, формирование цены на товар в магазине, тоже формула, но она может меняться в соответствии с требованиями маркетинга. Такую формулу не следует помещать в метод принадлежащий объекту с данными.

Доброго времени суток! Сегодня я продемонстрирую вам, как быстро и эффективно настроить PostgreSQL с помощью Docker Compose. Этот процесс займет всего несколько минут, но в результате вы получите полноценную базу данных PostgreSQL, работающую в изолированном Docker контейнере. Важные компоненты, такие как базы данных, таблицы и индексы, будут сохранены на вашей локальной машине благодаря использованию томов (volumes), что обеспечит надежность и доступность данных.

Попробуем собрать свой идеальный boilerplate для full-stack разработки в 2024 году. В этой статье мы будем постепенно собирать свой шаблон для быстрого запуска стартапов.

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

Привет, Хабр! Меня зовут Даша Кряжева, я продакт-менеджер, сейчас занимаюсь исходящим голосовым роботом в СберМаркете. С его помощью нам удалось автоматизировать 30% клиентских и партнерских обращений в контактный центр, но это не только про цифры. Проактивная коммуникация — это всегда про повышение лояльности и открытый диалог с пользователями.

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

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

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

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

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

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

У одной задачи может быть несколько способов решения. Возьмем классическую задачу программирования — задачу подсчета, в которой мы считаем, сколько раз каждый элемент списка встречается в нем. Способ решения этой задачи на Python менялся по мере развития языка. Именно об этом мы будем говорить в этой статье.

Большинство из нас присоединилось к программированию на Python с его третьей версии. Однако мы начнем с Python 1.4. Пристегните ремни, отправляемся в далекое прошлое — в 1997 год!

Одной из важных задач при имплементации корпоративных информационных систем является проектирование бизнес-процессов. Следуя [1], в ERP-проектах выделяется отдельный уровень внедрения: уровень процессов. Здесь ведется моделирование бизнес-процессов на основе общеизвестных графических нотаций, строятся модели As-Is и To-Be. Все разнообразие нотаций моделирования объединено термином CASE-средства, суть которых изначально заключалась как в проектировании, так и последующей автоматизации настроек и разработок ERP-систем [2].

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

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

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

В этой статье поговорим о практических стратегиях, повышающих эффективность использования GitHub Copilot при написании кода.

Привет, Хабр! На связи Виталий Киреев, руководитель R&D SpaceWeb. Это первая часть статьи про веб-безопасность — здесь я расскажу про главные уязвимости Server Side, покажу примеры и объясню, как защищать данные. 

Привет Хабрчанам! Меня зовут Дима Туркин, я — код-ревьюер на курсе «Python-разработчик» Яндекс Практикума и Python-тимлид.

Тема материалов по Python для начинающих и продолжающих свой путь разработчиков уже заезженная, поэтому в этой статье я постарался собрать ссылки на менее известные бесплатные ресурсы, но не менее полезные. Есть чем дополнить — пишите в комментариях!

Django - отличный фреймворк, но он, на самом деле, толком не дает, да и не должен давать, ответ на вопрос, каким образом лучше всего хранить вашу бизнес-логику. Хранение бизнес-логики в моделях или views имеет множество недостатков, которые обычно начинают проявляться при росте кодовой базы проекта. Чтобы решить эти проблемы, разработчики часто начинают искать способы выделения бизнес-логики в своем приложении.

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

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

На самом деле, изложенный далее текст относится не только к Django-проектам. Разрабатывая веб-приложения, используя другие инструменты, вроде Flask, люди используют те же концепции веб-разработки, причём часто именно в таком же виде, как они реализованы, в Django - views, request-response объекты, middlewares, модели, формы.

Как используется ключевое слово yield в Python? Что оно делает?

Например, я пытаюсь понять этот код (**):

def _get_child_candidates(self, distance, min_dist, max_dist):
    if self._leftchild and distance - max_dist < self._median:
        yield self._leftchild
    if self._rightchild and distance + max_dist >= self._median:
        yield self._rightchild

Вызывается он так:

result, candidates = list(), [self]
while candidates:
    node = candidates.pop()
    distance = node._get_dist(obj)
    if distance <= max_dist and distance >= min_dist:
        result.extend(node._values)
        candidates.extend(node._get_child_candidates(distance, min_dist, max_dist))
        return result

Что происходит при вызове метода _get_child_candidates? Возвращается список, какой-то элемент? Вызывается ли он снова? Когда последующие вызовы прекращаются?

** Код принадлежит Jochen Schulz (jrschulz), который написал отличную Python-библиотеку для метрических пространств. Вот ссылка на исходники: http://well-adjusted.de/~jrschulz/mspace/

Все сталкиваются с индексами на самых ранних стадиях освоения языка, как правило, при изучении списков. Вероятно, вы и так знаете, что индексация в Python начинается с нуля. У нас есть список movies, тогда операция movies[0] вернёт первый элемент списка.

Для новичков считать от нуля до девяти при работе со списком из десяти элементов поначалу кажется немного странным. Python в этом не уникален — в большинстве языков программирования реализован такой же подход (C, C++, Java, C# и JavaScript).

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

Привет! Меня зовут Александр Каленюк, и я крепко подсел на C++. Пишу на C++ 18 лет кряду, и все эти годы отчаянно пытаюсь избавиться от этой разрушительной зависимости.

Всё началось в конце 2005 года, когда мне довелось писать движок для симуляции 3D-пространства. В этом движке было буквально всё, чем язык C++ мог похвастаться в 2005 году. Трёхзвёздочные указатели, восьмиуровневые зависимости, C-подобные макросы повсюду. Кое-где – вкрапления ассемблера. Итераторы в стиле Степанова и мета-код в стиле Александреску. В общем, всё. Кроме ответа на самый важный вопрос: зачем?

Новички в Python часто спрашивают, как писать питонический код. Проблема — расплывчатое определение слова "питонический". Подробным материалом, в котором вы найдёте ответы на вопрос выше и три полезные книги, делимся к старту курса по Fullstack-разработке на Python.

Всем привет, хочу рассказать о своей утилите dcw (Docker Compose Workspace) для удобного управления тестовыми окружениями на базе docker-compose.