В этой статье описывается реализация задачи ручного подтверждения(acknowledgment) обработки сообщения в Kafka через ручную отправку смещения(commit offset) сообщения. Логика реализована с использованием Java, Spring и Kafka.

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

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

В статье рассматривается Continuous Deployment для БД с бесшовными релизами за счёт обратно-совместимых обновлений и автоматизации проверок совместимости с помощью подхода DB-First.

Всем привет! С вами снова я, Артём Харченков, руководитель разработки Crosstech Solutions Group. Ранее я рассказывал, как успешно пройти первый испытательный срок, а сегодня поделюсь опытом проведения собеседований глазами тимлида. Эта статья будет полезна как нанимающим менеджерам, так и соискателям, которые устраиваются на новую работу. 

Чтобы не быть голословным касательно своего опыта, приведу немного статистики: 

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

Написали свежий Ansible-плейбук? Отлично. Осталось-то всего ничего, ровно самая малость: установить нужные Python-зависимости на целевые хосты. Именно такой путь предлагается авторами инструмента. Но является ли он единственно возможным, или есть варианты?

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

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

Если у вас не просто большая компания, а целая экосистема с разными сервисами, IT-инфраструктура должна обеспечивать бесшовность. Клиенты и сотрудники могут входить в систему с разных устройств, но изменение информации в одном канале должно отображаться в других, а целостность данных сохраняться, даже если вход совершен в двух каналах параллельно. И в идеале — так, чтобы клиент не видел «внутренней кухни».

Меня зовут Владимир Паршин, я ведущий ИТ-инженер в СберТехе. Расскажу, как выстроена работа с бесшовностью в Сбере.

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

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

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

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

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

Статья будет полезна специалистам, строящим ядро/платформу мониторинга, и пользователям, ежедневно с ним взаимодействующим.

В рамках наших Java курсов "Из Middle в Senior" (предыдущие посты Миграция Java Spring Boot на Kotlin и «Работа с документами в Java») недавно вышел новый курс Startup: Spring Boot веб-приложение с хостингом и инфраструктурой на основе эволюции нашей платформы онлайн-обучения с 2016г.

В рамках курса есть много подходов, сокращающих количество кода/усилий разработчиков. Один из них: сквозная параметризация от сервисов до репозиториев, позволяющая сокращать количество кода ~3х. Код приведен на Java, но общий подход может быть использован в любом языке с параметризацией. Кому интересно:

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

У современного читателя может возникнуть резонный вопрос — почему программисты, а не IT‑ишники? Ответ кроется в самом заголовке. В 70-х, 80-х годах прошлого столетия, а точнее в СССР не было понятия IT‑и. Были понятия «кибернетика», «вычислительная техника», «электронно‑вычислительные машины» (или просто ЭВМ), и были понятия «программист» и «машинист». Если с программистом все понятно, то машинисты отвечали за эксплуатацию ЭВМ, их ремонт, обслуживание и т. п. Их еще называли электронщиками. Современный IT‑шник может задаться вопросом — какое обслуживание, какой ремонт? И будет прав, но прав применительно к современности. А тогда ЭВМ занимали огромные помещения и требовали большого штата различных специалистов:

Существует огромное количество самых разных языков программирования, их насчитывается несколько тысяч. Какие‑то — идеальны для работы, другие же созданы just for fun. К слову, есть ЯП, представленные программистами из неанглоязычных стран, в них операторы, функции и т. п. — все на родном для автора языке. Кроме того, некоторые страны стремятся развивать свои собственные IT‑индустрии, и использование местного языка в программировании может быть способом поддержать эту инициативу. Мы выбрали самые интересные на наш взгляд non‑English языки программирования.

Эта статья содержит рекомендации по написанию Dockerfile и принципам безопасности контейнеров и некоторые другие связанные темы, например про оптимизацию образов.

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

К счастью, большинство потенциальных проблем мы можем решить еще на этапе разработки.

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

• что такое PageSpeed;
• как измеряется и оценивается производительность;
• лирическое отступление: critical render path;
• способы оптимизации PageSpeed;
• для чего это нужно?

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

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

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

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

Итак, рассмотрим ситуацию, когда в команду разработки (или в командЫ разработки) приходит новый руководитель, о котором самим участникам команды ничего не известно. И этот руководитель — вы.

Всем привет, меня зовут Семён, я руковожу разработкой витрины объектов недвижимости в Домклик. Занимал должности от разработчика до директора в разных компаниях и разных странах, проходил этот путь несколько раз и не понаслышке знаю, каково это — выходить из зоны комфорта и в корне менять род занятий. Так, например, происходит при переходе с роли разработчика на роль тимлида. Но сегодня я хочу обсудить следующий возможный шаг в карьере тимлида — переход на директорскую (executive) должность. Он таит в себе много вызовов и неожиданностей. Статья будет интересна тем, кто собирается сделать такой карьерный шаг, а также новоиспечённым СТО, viceCTO, техдирам и прочим Е-level технарям. Прошу под кат.