Технотекст

Привет, я Антон Полухин из Техплатформы Екома и Райдтеха Яндекса. Моя команда разрабатывает userver — современный опенсорсный асинхронный фреймворк с богатым набором абстракций для быстрого и комфортного создания микросервисов, сервисов и утилит на C++.

Когда мы пишем какой‑то код для userver и для таких сложных проектов, как Boost, периодически мы сталкиваемся с нестандартными проблемами. И эти нестандартные проблемы требуют нестандартных решений. Вот о таких решениях мы сегодня и поговорим.

А именно:

— Посмотрим, как работают исключения на платформе Linux x86, и сделаем с ними что‑то интересное.

— Залезем ещё глубже под капот исключений и сделаем их ещё быстрее.

— Сделаем висячую ссылку на невалидный объект, и всё будет хорошо.

— А под конец то, что все любим, — погрузимся в шаблонное метапрограммирование.

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

Полгода назад команда Gradle представила новый продукт — Declarative Gradle. Команда Spring АйО, со своей стороны, провела исследование и готова поделиться результатами. 

TL;DR: технология всё ещё активно развивается, но пока что не поддерживается привычными инструментами, такими как IntelliJ IDEA. Несмотря на это, нам удалось запустить Spring Boot приложение!

В Spring Data 3.1 появилось новое API для итерирования по большому объему данных: Scrolling API. Давайте изучим его, посмотрим на практические применения с примерами кода и преимущества по сравнению со всем известным Pageable. А также разберём, чего Scrolling API пока не хватает, и можно ли его вообще брать в свои проекты. Если хотите выяснить, как с новым API в теории ускорить пагинацию больших данных, — заходите под кат.

На российском рынке сложилась сложная ситуация с IDE для Java-разработчиков. Новости, связанные с ограничением скачивания IntelliJ IDEA Ultimate, недоступностью JetBrains маркетплейса и блокировкой лицензий, которые использовались на территории РФ порождают огромное количество вопросов, на которые не у всех есть ответы.

Команда Spring АйО подготовила цикл статей, в которых постарается ответить на все вопросы, связанные с уходом IntelliJ IDEA из России.

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

Меня зовут Евгений Грибков. Я ведущий программист в центре технологий VK. В этой статье мы рассмотрим одно из возможных решений создания скрипта перезаливки заданных таблиц из одной БД в другую на примере MS SQL.

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

Вам нужно только одну форму? Тогда только призрак. Романтичный вариант названия – «привидение».

Привет, Хабр, это моя первая статья. Меня зовут Константин, я системный инженер в компании ГНИВЦ. Здесь я хотел бы вам рассказать, что такое Envoy и как с его помощью можно упростить жизнь разработчикам и повысить надёжность взаимодействия микросервисов, минуя инфраструктуру для кого-то страшного и непонятного Kubernetes, а используя простой и старомодный Docker. Также эта статья поможет познакомиться с Envoy поближе и узнать, как он шагает в ногу с таким проектом как Istio.

Всем привет! Я Сергей, работаю в B2B-команде Яндекс Маркета последние 3,5 года. Как уже понятно из заголовка, сейчас я вам расскажу про yet-another-миграцию с базы на базу, которая началась в середине 2021 года и заняла почти год. Получается, мемуары.

Вас ждёт рассказ о том, как мы:

- несколько месяцев чинили тесты и делали трансформер;

- десятки раз переливали данные;

- чинили баги незаметно для пользователей;

- заставили сервис работать на PostgreSQL быстрее, чем он работал на Oracle.

Ещё 10–20 лет назад многие думали, что роботы под управлением искусственного интеллекта возьмут на себя всю тяжёлую и опасную работу на предприятиях. Однако нейросети нашли применение в офисах, колл‑центрах, службе поддержки и даже стали полезны людям из творческих профессий — копирайтерам, дизайнерам, программистам. Тем не менее создание роботов, которые могут самостоятельно выполнять сложные физические манипуляции с материальными объектами, остаётся трудной и нерешённой задачей.

В этой статье я расскажу, как команда ML R&D в отделе робототехники Маркета создаёт роборуку и обучает нейросети, благодаря которым робот взаимодействует с физическим миром.

Всем привет! Меня зовут Сергей Яхницкий. Я пишу на Python уже больше шести лет, техлид в Яндекс Такси, Python-евангелист и член Python-комитета Яндекса (аналог Python Steering Council).

Человек я простой, звёзд с Гитхаба не хватал: до того, как я устроился в Такси, я мирно писал маленькие бэкенды на Python. А потом меня прорвало: кодогенерации, CI/CD, кучи тестов, монорепа и прочее. Вот тут-то моя питоничья душа и воспряла. Решил я всё автоматизировать, обновить всё, что движется, а что не движется — подвигать и обновить. Из этого вышел мой рассказ.

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

Да, может. На этом статью можно было бы закончить. Спасибо, что дочитали до конца, приходите поделиться своим опытом в комментариях.

Если серьёзно, карьера мобильного разработчика, который хочет вырасти в большого руководителя, может складываться по-разному. Например, мой путь начался в 2013 году, и за это время я успел поработать и в маленьких стартапах, и в больших корпорациях. Сейчас я Director of Engineering в Яндекс Go. Последние шесть лет я управляю разными командами разного размера: от 5 до 200+ человек.

В этой статье я хочу рассказать, какие есть пути развития в мобильной разработке, что делать, если ты уже тимлид, кто такие крутые Individual Contributors (топовые разработчики) и как стать одним из них. Обо всём этом читайте под катом: попробуем разобраться, как расти и куда это может завести.

Привет, Хабр! Меня зовут Андрей Курье, уже почти два года я работаю инженером по автоматизированному тестированию в СберТехе — пишу тесты для Platform V Pangolin. Это специальная доработанная сборка PostgreSQL, целевая СУБД в Сбере и не только. А до перехода в тестирование я был сисадмином 14 лет. Администрировал парк пользовательских хостов, настраивал и поддерживал серверы, обслуживал СКД и видеонаблюдение в петербургском метрополитене. К слову, админскую работу я любил, мне было хорошо и комфортно, но при этом понимал, что всё вокруг меняется, а мои обязанности — нет. К тому же вырасти из сисадминов на моей работе было некуда, да и просто хотелось попробовать себя в другой области.

И вот я иду учиться на разработчика, получаю диплом, выхожу на Headhunter, получаю отказ за отказом, с трудом нахожу проект на полставки, но платят мало, я продолжаю работать сисадмином по ночам... Мой переход в новую профессию — от первого отклика до получения полноценного оффера — занял полтора года. В этой статье расскажу, как я сменил работу в 35+ лет, и что помогало, а что мешало мне на этом пути. Надеюсь, будет полезно тем, кто думает о том, чтобы поменять направление. Добро пожаловать под кат.

Привет, Хабр! Меня зовут Евгений Узянов, я продуктовый аналитик в команде геймификации Купера (ex СберМаркет). Когда я только начинал изучать методы количественного тестирования, я искал информацию в большом количестве источников: университетские лекции, онлайн-курсы, литература разной степени глубины и, конечно же, ютуб. В значительном количестве случаев при знакомстве с очередной статистикой информация преподносилась в следующем формате:

- Держи страшную формулу

- Вот какие-то графики с хвостами

- Ну а дальше все понятно

- Иди работай

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

Привет! Меня зовут Дима, я архитектор в Купере. Сегодня расскажу о шаблоне проектирования Strangler, который мы использовали для поэтапного выноса бизнес-логики из монолитной системы в отдельный сервис. 

Сначала обратимся к первоисточнику, а затем перейдем к практическим моментам, с которыми столкнулись в процессе работы. Поехали!

Привет, Хабр! Меня зовут Капитолина Кузнецова, я Ruby-разработчик и на своём текущем месте работы в Купере (ex СберМаркет) доросла до роли тимлида. За 2,5 года я, так сказать, освоилась в этом статусе и, если верить моей команде, руководитель из меня получился неплохой, но вьетнамские флэшбэки о своих первых месяцах работы в новой роли ещё свежи.

Быть начинающим тимлидом — это...

- когда встречи занимают по семь, восемь, а то и девять часов подряд;

- когда ты целый день что-то делаешь, дико устаешь, а в конце не видишь никакого результата;

- когда о Jira знаешь больше, чем о собственной семье, а встречи с друзьями планируешь на новогодние праздники 2025 года.

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

Привет, Хабр! Я Евгений Малышев, SRE-инженер в Купере (так теперь называется СберМаркет). Моя основная задача — это надежная работа сервисов фронтенда, и немалую роль в этом играют правильно построенные пайплайны CI/CD. В этом нам помогает Gitlab CI. В компании мы широко используем этот инструмент для создания общих шаблонов для сервисов на различных языках. На уровне отдельного репозитория легко расширить или настроить шаблонные джобы и добавить свои.

До этого у меня был опыт с Jenkins и Azure Devops, так что Gitlab CI мне показался довольно простым: есть стадии, есть правила запуска джоб с shell-подобным синтаксисом, да и скрипты джоб тоже используют bash-интерпретатор. Но в процессе близкого знакомства не раз возникали ситуации, когда поднимается то одна бровь, то обе, а то и руки в праведном гневе. Заходите посмотреть, какую коллекцию граблей собрал я.

Весь код с примерами граблей можно посмотреть в репозитории.

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

Мы уже рассказывали о том, как приручили робота-пайщика, как делаем устройства и тестируем их. Теперь хотим поделиться опытом разработки полноценного Embedded Controller для ПЛК на Linux — какие задачи решает, как устроен и что у него под капотом в прошивке.