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

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

Логические операции играют важную роль в программировании. Они используются для создания условных конструкций и составления сложных алгоритмов. В Python для проведения логических операций используются логические операторы:

not — логическое отрицание

and — логическое умножение

or — логическое сложение

В этой статье мы поговорим о неочевидных деталях и скрытых особенностях работы логических операторов в Python.

Приветствую всех, друзья! Наша последняя статья по созданию собственного API на FastAPI вызвала огромный интерес, и за это я искренне благодарен.

Ранее мы рассматривали базовые аспекты работы с FastAPI: различные типы запросов, их валидацию и обработку, а также ответы на эти запросы. Однако, это лишь верхушка айсберга.

Уже на данном этапе код становится громоздким и сложным для понимания. К тому же, хранение данных в JSON‑файлах — это далеко не самый профессиональный подход. «Нормальные ребята» используют SQLAlchemy, причем асинхронно.

Сегодня мы займемся интеграцией асинхронной SQLAlchemy в наше FastAPI‑приложение. Для упрощения навигации и понимания кода я предложу структуру проекта, которую сам использую в каждом FastAPI‑приложении.

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

Всем привет!

В этой небольшой статье я опишу простой способ, как можно автоматизировать 10 000+ ручных протыкиваний мышкой или клавиатурой на нескольких удаленных Linux-машинах (Xserver + SDDM).

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

А если нет?

Spring разработчики часто пишут документацию и README/HELP файлы к своим приложениям. Часто это делается в Markdown файлах. Markdown плагин в IntelliJ IDEA распознает файлы, предоставляет специальный редактор с подсветкой, автокомплитом и форматированием, а также дает визуальное отображение в панели предварительного просмотра в реальном времени. Кроме стандартной функциональности в IntelliJ IDEA есть пару уникальных фич, которые команда Spring АйО хотела бы выделить особенно.

Docker и Kubernetes — два инструмента, которые прочно вошли в арсенал современных разработчиков. Хотите разобраться в основах контейнеризации и оркестрации? Наша статья поможет вам в этом, раскрывая ключевые концепции и принципы работы этих технологий.

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

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

Привет, Хабр! Я  исполнительный директор по разработке департамента ML и BD Газпромбанка. Сегодня хочу поговорить с вами о деплое.

По данным, приведенным в Google SRE book, до 70% проблем происходит вследствие изменений в уже работающих системах. По моим личным ощущениям, это близко к правде: если у вас хорошо спроектированное и написанное приложение и стабильная, отлаженная инфраструктура, именно деплой — узкое место (которое можно улучшить). Для минимизации рисков Google SRE BOOK рекомендует использовать постепенные выкаты, быстро и точно анализировать проблемы, а в случае необходимости легко откатываться обратно. 

Эта статья о деплое в Kubernetes, потому что это самая популярная инфраструктурная платформа, которая уже имеет множество возможностей для построения отказоустойчивых выкатов. А то, чего не хватает «из коробки», покрывается возможностями инструментов развитой экосистемы. 

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

Те, кто больше любит слушать, чем читать, могут посмотреть мой доклад про это на HighLoad++. Остальным — добро пожаловать под кат.

Одним из важным инструментом разработчика, в не зависимости от языка (и религиозных убеждений), является система контроля версий (VCS). И практически промышленным стандартом стала такая распределенная система как GIT. В повседневной работе мы (разработчики, DevOps инженеры, технические писатели и все причастные) используем ее чтобы нести людям добро и свет объединять усилия команд в работе над нашими проектами. И все давно уже выучили «на зубок» основные команды (если не выучили то бегом учить, тут есть отличная книжка) и превратили в рутину то что совсем не давно (олды тут?) казалось гениальным, сложным, а кому то магическим. А современные IDE еще больше нам упростили жизнь, спрятав от нас командную строку и git команды, заменив на возможность кликать мышкой. Но постойте, разве вам в детстве не было интересно понять как та или иная игрушка устроена внутри, как работает холодильник или мотор в папиных жигулях (олды все же тут?)? Так вот и мне стало интересно заглянуть под капот GITу. Конечно как и с любым сложным механизмом уровень этого «заглядывания» под капот может быть разным, кому то будет достаточно увидеть крышку мотора и отверстие куда лить незамерзайку, а кому то «заглянуть под капот» это дойти до марки стали используемой для изготовления той или иной детали жигулей. Поэтому давайте сразу обозначим уровень нашего погружения в этой статье. В статье мы рассмотрим в деталях что происходит когда мы делаем привычные нам «git clone/push», посмотрим как этот процесс устроен и какие есть в нем возможности. Сущности и процессы, которые конечно же останутся за рамками этого повествования, можно будет самостоятельно найти (ссылку я указал выше), ибо охватить такую обширную тему как Git, а тем более его подкапотное пространство, не представляется возможным за раз. Так что все кому интересно прошу под кат.

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

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

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

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

Статей на тему много, но, видимо, недостаточно. Последние 10 лет в 4-х разных компаниях время от времени слышу от коллег:

— Не могу пошарить экран с кодом, у меня другая ветка сейчас.

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

— Стаскивать ветку для просмотра ПР? Это же неудобно, надо "стэшить" изменения, ветку переключать.

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

Привет, ХАБР! Недавно я писал научную статью с AIRI по графовым рекомендательным системам. Это был мой первый практический опыт работы с этой технологией, поэтому пришлось углубиться в исследования и изучение доступных материалов. Я решил, что пока я разбираюсь в этой теме, было бы полезно поделиться своими находками с вами.

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

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

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

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

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

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

— Добрый день, хотим дизайн вот заказать для упаковки нашей продукции на маркетплейсах.
— Ой, ну это короче бюджет нужен.
— А по срокам как?
— Давайте сначала ТЗ составим, а там уже и сроки почувствуем.

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

В чём проблема?