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

Основная цель такого разделения — минимизация радиуса поражения при возникновении сбоев и упрощение масштабирования системы.

За время существования индустрии разработки игр формул разных механик, способных развлечь нас, придумали не одну сотню. Что-то умерло засветившись в паре игр, что-то ушло со временем, какие-то существуют до сих пор. Есть и такие, которые не просто выжили, но стали мейнстримом, хотя только портят нервы игрокам. Игровой дизайн большинства старых игр, от второго фолыча до первого FarCry и пятью активными перками, пусть и не был вершиной искусства - затягивал не хуже современных песочниц с миллионом активностей. Редкую игру захочется пройти второй раз, а как вспомню, что на прохождение можно потратить под сотню и больше часов - думаю, а оно мне действительно было надо? Можно же было заняться чем-то более интересным. Я знаю, чем закончился второй фолыч, знаю это уже четвертый раз, но каждый раз игра удивляет меня чем-то новым. А вот нового "Аватара" бросил на половине, слишком много всего и все недоделанное, и прозрачные стены... просто бич игры. И тут вопрос, чего-то не хватает в этой раздутой, перекачанной сотней механик игре? Только задумайтесь - в аватаре больше сотни основных механик, которые влияют на окружение. Может в играх что-то потерялось? Хотя "потерялось" - звучит странно - за столько лет индустрия только создала просто море всего нового. Статья ориентирована на "побурчать", так что не ждите каких-то великих секретов и тонкостей мастерства.

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

Системное тестирование - это этап тестирования программного обеспечения, на котором тестируется полный и полностью интегрированный программный продукт на основе спецификации программного обеспечения (SRS: Software Requirement Specification). Основная цель такого тестирования — это процесс оценки, который охватывает аспекты, связанные с бизнесом, функциональной спецификой и потребительскими ожиданиями. 

Анонимная сеть Hidden Lake (HL) - это децентрализованная F2F (friend-to-friend) анонимная сеть с теоретической доказуемостью. В отличие от известных анонимных сетей, подобия Tor, I2P, Mixminion, Crowds и т.п., сеть HL способна противостоять атакам глобального наблюдателя. Сети Hidden Lake для анонимизации своего трафика не важны такие критерии как: 1) уровень сетевой централизации, 2) количество узлов, 3) расположение узлов и 4) связь между узлами в сети.

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

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

В этой статье рассмотрим, как реализован HLL в PostgreSQL.

В этой статье описывается реализация задачи ручного подтверждения(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‑шник может задаться вопросом — какое обслуживание, какой ремонт? И будет прав, но прав применительно к современности. А тогда ЭВМ занимали огромные помещения и требовали большого штата различных специалистов: