Привет, меня зовут Денис Агапитов, я руководитель группы Platform Core компании Bercut.

Сегодня хочу поговорить об одном из lock-free алгоритмов в Java. Разберём как с ним связано ключевое слово volatile и паттерн immutable.

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

В прошлой статье мы рассмотрели способы запуска наших проектов на удаленном VPS. Для этого мы арендовали хостинг, создали шаблонное приложение, перенесли его на хостинг через простое копирование через ssh и через git clone, запустили через dotnet run / dotnet publish, а также развернули приложение в докере.

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

Приветствую тебя, Хабр! Сегодня мы попробуем разобраться, как написать интеграционный\сервисный\авто тест для Spring Boot приложения, которое взаимодействует с внешним миром исключительно с помощью Kafka.

Периодически меня на начальном курсе просят дать "список всех-всех команд с кратким описанием что делает"... Ну прям "всех-всех". И ведь если искать в интернете "такие" справочники существуют - либо про "20-30 команд, но самых важных", либо с неточностями и устаревшей информацией. Так что предлагаю вашему вниманию свою версию такого "краткого" справочника (на 300, 515, 612, 716, 842, 1005, 1171 команд) с ссылками на wiki-описание и на cheat.sh-примеры наиболее важных команд.

Я всегда знал, что если отвлекать человека во время работы, это вредит делу. Но до конца не осознавал, насколько это серьёзная проблема. Особенно для разработчиков ПО.

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

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

Привет, жалкие людишки!

Если вы подумали, что название статьи — кликбейт, готов вас огорчить, приведя аналитику и будущие тенденции по «хьюманзамещению». Также осмелюсь разбить уже весьма прогнившие заблуждения и стереотипы о беспомощности ИИ без человека, наподобие «главное быть хорошим специалистом и нейросети тебя не заменят» и прочие влажные фантазии, в которые и я, будучи в свое время разработчиком, верил какое‑то время. В конце приведу три дальнейших сценария развития ИИ, каждый из которых радикально поменяет текущую ситуацию. Эта статья в первую очередь для тех, кто думает, что они смогут и дальше спокойно работать, не взаимодействуя с «нейросетками» и для тех, кто думал, что они будут для нас просто «ассистентами». Не будут:) и моя цель в своей статье — это доказать.

Привет! Меня зовут Настя, я старший системный аналитик в X5 Tech. Я рисую sequence-диаграммы каждый день на протяжении четырёх лет. За это время я прошла все круги ада по Данте, то есть попробовала разные инструменты для рисования этих самых диаграмм. Пока не встретила его – PlantUML. 

Что удивительно, инструмент довольно не новый, но тем не менее лучше него я пока не встречала. А ещё удивительно, что он не особо популярный. Когда мы запустили в управлении системного анализа первый воркшоп по PlantUML, за 3 минуты после анонса пришли 12 заявок от аналитиков разных грейдов – от Junior до Lead. 

В процессе подготовки материалов к воркшопу мы искали статьи и литературу, которые помогли бы дополнительно изучить sequence-диаграммы в PlantUML. Ничего интересного мы не нашли. 

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

Поэтому и появилась эта статья. 

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

Педантичность, дотошность, внимательность к деталям у аналитиков бывает, что перерастает в модное нынче слово "душность". Где та граница, когда вы считаетесь классным аналитиком, а когда - уже все вас тихо ненавидят?

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

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

Меня зовут Никита Шевченко и однажды я заигрался в красивый инструмент, да так, что в какой-то момент потерял суть и начал терять пользу. А потом начал придерживаться правил ведения заметок и даже придумал несколько своих.

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

Привет, Хабр! Решил представить здесь самые интересные проекты/самоделки/концепции, которые делал сам на протяжении последних семи лет. Если КДПВ сделала своё дело, добро пожаловать под кат! Осторожно, много фото.

Недавно появились мысли походить на собеседования чем я успешно занялся. Если конкретно - смотрел лидовскую/сеньерскую позиции на Python и Golang(но статья может пригодиться backend разработчикам в целом). Не ставлю целью статьи объять все не объятное и дать какие-то гарантии. Я лишь зафиксирую данные для себя на будущее.

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

Сразу сделаю пометку, что некоторые навыки/ресурсы специфичны(по типу нарешивания Leetcode), но отталкиваемся от текущих реалий рынка.

По мнению Артема Закируллина*, одна из фундаментальных проблем, с которой сталкиваются разработчики при анализе кода – высокая когнитивная нагрузка. Это не абстрактное, а реальное ограничение возможностей, которое стоит времени и денег. На чтение и понимание кода, тратится больше времени, чем на его написание. Поэтому, разработчику нужно постоянно задаваться вопросом: не пишет ли он код, чтение которого создает чрезмерную когнитивную нагрузку?

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

*Обращаем ваше внимание, что позиция автора может не всегда совпадать с мнением МойОфис.

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

Уверен, что заголовок вызвал здоровую реакцию — “ну опять началось…” Но позвольте завладеть вашим вниманием на 5-10 минут, и я постараюсь не обмануть ожидания.

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

Для того, чтобы была ясность в том, что такое RPC, предлагаю рассматривать стандарт JSON-RPC 2.0. C REST ясности нет. И не должно быть. Все, что нужно знать о REST — он неотличим от HTTP.

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

На проекте используется spring boot 2.6.4 и kotlin 1.5.31. Также для конфигурации сервисов используется spring cloud config server, где в качестве backend используются Git + Vault.