Если вы занимаете руководящую должность, очень важно регулярно проводить индивидуальные встречи с сотрудниками из своей команды. “Зачем, если я и так вижу их каждый день, и мы обсуждаем все, что происходит?”. Эти встречи не только помогают понимать, как чувствуют себя коллеги, но и дают возможность откровенно дать и получить обратную связь без посторонних. А также предполагают, что оба участника будут готовиться к собранию, рефлексируя насчет прошедшего периода после предыдущей встречи. 

Я Алексей Анисимов, в настоящий момент управляю юнитом разработки в hh.ru и уже 10 лет руковожу разными людьми и командами в области ИТ. За это время я провел большое количество встреч 1 на 1 с сотрудниками — попробовал различные варианты, сталкивался с трудностями и совершал ошибки. Все это в результате помогло мне выработать для себя определенные принципы проведения индивидуальных встреч, которыми я хочу поделиться в статье.

Автор статьи обращает внимание на проблему, которая заключается в использовании метода __init__ для сложной логики создания объектов, что приводит к разрастанию и усложнению кода. Статья предлагает использовать вспомогательные методы, чтобы разделить логику создания объектов на более мелкие и понятные части. Это упростит код и облегчит понимание того, как объекты создаются и инициализируются.

Привет, Хабр! Если вас заинтересовал заголовок этой статьи, значит, вас интересует созданием телеграм-ботов, и вы стремитесь к совершенству в этом. Разработка телеграм-ботов требует не только креативности, но и правильной архитектуры. В этой статье мы рассмотрим 9 архитектурных антипаттернов, которые могут стать серьезными преградами на вашем пути к созданию бота.

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

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

Аналитика для телеграм-ботов представляет собой ключевой инструмент для понимания того, как пользователи взаимодействуют с вашим ботом, какие запросы они делают, какие функции бота наиболее популярны, и какие моменты требуют оптимизации. Эти данные обеспечивают ценную информацию, которая позволяет вам принимать информированные решения и совершенствовать бота с течением времени.

В этой статье мы рассмотрим как реализовать аналитику для телеграм-бота.

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

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

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

Задача: Необходимо очистить данные о продажах компании за последние несколько лет с помощью библиотеки Pandas.

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

Есть такое понятие – ошибка выжившего. Грубо говоря, о явлении, тенденции или событии судят по людям, которые прошли его успешно – выжили. Совершенно игнорируя информацию о тех, кто успеха не достиг. В результате случайная удача интерпретируется как устойчивая вероятность. Если интересна мат.часть – почитайте Нассима Талеба или Даниэля Канемана. Их книги существенно дешевле курсов по ИТ.

Я опишу типичные ошибки тех, кто не выжил. И, соответственно, не вошёл в ИТ. Всё из опыта личных наблюдений.

Да, если «тут всё неправда», «а вот мой друг Коля успешно…» или «а у меня получилось» - прекрасно, текст не про вас и не для вас. Вы и ваш друг Коля – выжившие.

Всем привет, с вами Кирилл Мыльников, frontend разработчик компании Usetech.

Сегодня я хочу рассказать о вертикальном и горизонтальном центрировании CSS (Cascading Style Sheets). В сети есть много статей на эту тему, но я хочу выделить все виды горизонтального и вертикального центрирования с примерами.

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

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

В этой статье я разберу следующие виды центрирования:

— Горизонтальное центрирование;
— Вертикальное центрирование;
— Горизонтальное и вертикальное центрирование.

Начнём.

Привет, читатель!

Меня зовут Василий Кудрявцев, и вот уже ~10 лет я занимаюсь нагрузочным тестированием, а из них последние 1,5 года – в компании РТЛабс.

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

Здесь, на Госуслугах, мы пока только конструируем мечту каждого нагрузочника — свой отдельный, выделенный, рабочий (!) тестовый стенд.  Особенно это мечта актуальна для небольших продуктовых команд.

Системы мониторинга — очень нужная для админа вещь, ведь они позволяют получать от сервисов метрики, которые:

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

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

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

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

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

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

Статья подготовлена на основе открытого занятия из видеокурса по Apache Kafka. Авторы — Анатолий Солдатов, Lead Engineer в Авито, и Александр Миронов, Infrastructure Engineer в Stripe. Базовые темы курса доступны на Youtube.

Понимайте свою программу без ущерба для производительности

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

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

Я делаю много ревью для чужого кода на Ансибл и много пишу сам. В ходе анализа ошибок (как чужих, так и своих), а так же некоторого количества собеседований, я понял основную ошибку, которую допускают пользователи Ансибла — они лезут в сложное, не освоив базового.

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

Ожидаемый уровень читателя — уже написано несколько тысяч строк ямла, уже что-то в продакшене, но "как-то всё криво".

• Собирается ли он?
• Проходят ли автотесты?

Вечерняя школа Слёрма дает введение в Kubernetes с нуля для тех, кто хорошо знает Linux.
У нас бесплатные лекции и платная практика.

На этой неделе разбирали основы Kubernetes.

Лекция №1: Введение в Kubernetes, Pod, Replicaset

Лекция №2: Deployment, Probes, Resources

В конце лекции студенты получили домашнее задание:

• Запустить Pod, Replicaset, Deployment
• Посмотреть что происходит на уровне Docker
• Добавить в Deployment Startup Probe
• Узнать как управлять ресурсами Huge Page
• Почитать про QoS
• Ознакомится с документацией

Это задание мы разбирали на платной практике.

(По неизвестной причине встраивание не работает)