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

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

Меня зовут Камиль Калимуллин, я — IT-предприниматель, основатель компании AdvantShop и крупнейшей региональной IT-конференции «Стачка».

В 2023 году на «Стачке» выступила Вера Маневич, HRD с крепким опытом работы в IT, ментор и преподаватель MBA. Она много лет исследует тему офбординга и уверена, что это ключевой навык всех руководителей и HR. 

Делюсь видео доклада Веры и основными тезисами выступления.

Привет, Хабр!

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

Всем привет! Одна из моих рутинных задач - это подъем новых проектов и микросервисов в облаках. Для этого практически всегда нужны домены и поддомены с наличием SSL сертификата. У меня выработался подход, с помощью которого я автоматизировал процесс выдачи сертификатов с помощью certbot. О чём и хочу рассказать.

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

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

Всем привет! Меня зовут Миша, работаю фронтэнд‑разработчиком в VK в команде Облака Mail.ru, и я хочу разобрать различные виды тестов, дать их сравнительный анализ и применимость. Сразу скажу, тут не будет практики написания тестов. Потому что это нереально сделать внутри одной статьи, необходимо разобрать: теорию тестирования, классов эквивалентности, различие подходов/методов к тестированию, комбинаторику состояний, правильное использование моков и стабов, понимание чистых функций, знание архитектуры приложения. Поэтому предлагаю сконцентрироваться на видах тестирования и начать с «идеального теста».

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

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

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

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

Рассказываю, какие ошибки при работе с API допускают не только новички, но и профессионалы, и как сделать, чтобы эти ошибки возникали как можно реже или не появлялись вовсе.

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

В этой статье я хотел бы рассказать о способе сбора статистики из node.js приложений, которые запущены в PM2, и экспорт этих данных в Prometheus.

В предыдущих статьях, мы уже обсудили налоговое и валютное законодательство РФ, как ИП в РФ заплатить налоги с иностранных доходов, особенности налоговой системы Грузии и Армении и продолжаем разбирать налоговые правила государств ЕАЭС.

В этом материале по Казахстану (РК), я собрал основную информацию, которая позволит физическим лицам, фрилансерам, фаундерам IT-компаний, стартапов, провести начальное налоговое планирование релокации / эмиграции в юрисдикцию, минимизировать риски, кроме того информация заслуживает внимания действующих ИП / ТОО в РК, так как ведение бизнеса в РК имеет множество неочевидных, на первый взгляд особенностей.

Если вы собрались плотно погрузиться в тему Doman Driven Design (DDD), о том как его применять, как использовать, для чего он нужен, и как с ним связаны Command and Query Responsibility Segregation (CQRS), Event Sourcing и другие термины из мира DDD то можно воспользоваться планом обучения, который последовательно погрузит вас в эти темы и поможет сориентироваться. Часть информации на русском, часть на английском языке, так как русскоязычных аналогов я не смог найти.

Меня зовут Настя, я руководитель службы инструментов репозитория в Yandex Infrastructure. Больше 15 лет я проработала в IT-индустрии: сначала как разработчик, потом тимлид, техлид, менеджер проектов и руководитель службы. За это время несколько сотен человек рассказали мне о своём карьерном пути: кто-то собеседовался со мной как с нанимающим менеджером, кто-то приходил ко мне на менторинг, кто-то расширял свой нетворк, как теперь модно говорить. Из этих разговоров можно выделить причины недовольства работой, которые я вижу у людей чаще остальных. Одна из главных причин — ошибка выбора вакансии.  

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

Когда я пошла учиться на большой оффлайновый курс разработки ПО, дело стопорилось: начали мы с С/С++ и иногда доходило до того, что я клала голову на клавиатуру и плакала. Шутка ли, то 273 ошибки при компиляции, то простенькая программа попадает в вечный цикл… Такое оно, обучение с нуля. И, вероятно, всё бы бесславно закончилось, если бы я не обратилась к своей любимой студенческой уловке: забываем интернет, берём в руки книгу (в вузе это было вообще несложно, я ещё звуки dial-up помню и карточки). Справочник Шилдта, убийственно огромный том Страуструпа, клавиатура и постоянная работа с кодом — и дело не вот полетело, но пошло до достойной сдачи экзаменов. Книги не подвели: доходчивее без того неплохих лекций, подробнее статей и обсуждений в интернете.

Мне тут подумалось — а читают ли что разработчики и айтишники в 2022 году? Читают. Рекомендации оказались дельными.

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

Привет, друзья!

Представляю вашему вниманию первую часть перевода этой замечательной книги по WebRTC. Данная часть посвящена тому, что такое WebRTC, процессу сигнализации и установки соединения (первые 3 части оригинала).

Справедливости ради следует отметить, что на Хабре уже публиковался "вольный" перевод первых 2 частей оригинала (часть 1, часть 2), но автор по какой-то причине решил не продолжать. Я, свою очередь, решил начать с самого начала, без лишних вольностей и сокращений.

Ссылка на вторую часть перевода.

Если вам это интересно, прошу под кат.

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

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

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

Время от времени мне приходится проводить собеседования. И сегодня я хочу поделиться моими любимыми вопросами на тему Redux. К сожалению, вопросы немного устарели, т.к. они касаются компонента высшего порядка connect, который активно заменяют на хуки. Но connect может уже и не сильно актуален, а принципы на которых он построен абсолютно не изменились. (Данная статья является расшифровкой видео).

Эта статья является переводом материала «Untangling Microservices, or Balancing Complexity in Distributed Systems».

Расцвет микросервисов закончился. Uber преобразовывает тысячи микросервисов в более управляемое решение [1]; Келси Хайтауэр предсказывает, что будущее за монолитами [2]; и даже Сэм Ньюман заявляет, что микросервисы никогда не должны быть выбором по умолчанию, а скорее крайним средством [3].

Что происходит? Почему так много проектов стало невозможно поддерживать, несмотря на обещание микросервисов простоты и гибкости? Или все-таки монолиты лучше?

В этом посте я хочу ответить на эти вопросы. Вы узнаете об общих проблемах проектирования, которые превращают микросервисы в распределенные большие комки грязи (distributed big balls of mud), и, конечно же, о том, как их избежать.

За несколько недель до 14 февраля системе Dodo IS немного поплохело под нагрузкой. Одной из причин стало то, что в backend’ах мобильного приложения и сайта не совсем корректно работали политики поверх HttpClient’а (Retry, Circuit Breaker, Timeout). В этой статье я хочу поделиться с вами потенциальными проблемами, которые могут возникнуть при неправильном использовании таких политик.