Привет! На связи Миша Меркушин. Я тимлид команды Ruby Platform, ответственной за разработку внутренних библиотек и улучшение архитектуры микросервисов на Ruby в СберМаркете. Эта статья про архитектурный паттерн Outbox и инструмент, который мы создали и итерационно развивали внутри команды и лишь недавно «выпустили» его в мир. Он решает проблему обеспечения надежной и согласованной отправки сообщений из приложения, гарантируя, что сообщение будет отправлено после успешного завершения транзакции базы данных.

Всех приветствую в своей новой статье! Меня зовут Елизавета Акманова. С некоторыми читателями уже знакомы с предыдущих тем, для новых представлюсь: я системный/бизнес аналитик с опытом работы 3 года. Было много проектов разного уровня и сложности: начиная с монолитов в команде из 4 человек, заканчивая 50+ микросервисами из 90 человек. Но все проекты объединяло одно: API. Абсолютно в каждом присутствовал этот термин, приходилось работать с проектированием API, и сегодня я хотела бы рассказать про подходы, как это можно делать и подчеркнуть особенно метод API-first. 

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

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

А чтобы картинка не получилась однобокой, сделаем мы это вместе: точку зрения команды бэкенда расскажет Наташа, системный аналитик (SA) компании Интаро, взглядом фронтенда поделится Лиза, аналитик (BA) компании Surf.

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

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

На практике же ретроспективы часто получаются поверхностными и малопродуктивными. Участники отмалчиваются или обсуждают одни и те же боли из раза в раз; скучают или параллельно занимаются другими делами; уходят со встречи с ощущением впустую проведенного времени.

Хорошие новости: можно по‑другому. Повысить вовлеченность команды в ретроспективу, помочь увидеть конкретный результат своих усилий по улучшению работы. Уйти от вопросов «Что будем обсуждать на ретро?» и «У нас все хорошо?» к прозрачной картине того, что происходит с командой, чего удалось достичь и куда двигаться дальше. Помогут нам в этом процессные метрики.

Привет! Меня зовут Филипп Бочаров, я руководитель центра мониторинга и наблюдаемости в МТС Digital. Мы делаем распределённую трассировку, чтобы контролировать качество наших сервисов и предотвращать аварии. В этой статье разберём, как добиться понятной и прозрачной работы от сложных распределённых систем.

За время, прошедшее с прошлого доклада, количество обрабатываемых в единицу времени спанов выросло в несколько раз. Рассмотрим, какие архитектурные решения начали «поджимать», и как команда МТС их исправляла.

Как описать хороший код в трех словах? Исходя из опыта — это код, который [приятно поддерживать и эксплуатировать]. СОЛИД, SOLID, СОЛИД... Редко код ревью обходится без упоминания этих принципов, но для разработчика это не означает ничего хорошего. А что, если я скажу вам, что есть альтернатива? Недавно я наткнулся на одну англоязычную статью в блоге автора по имени Dan North. Он поднимает крайне интересные темы: написание хорошего кода, поддержка кодовой базы, порочные практики следования устаревшим трафаретам. 

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

Привет, Хабр! Меня зовут Антон Морозов, я инженер по тестированию в Яндекс 360. Я работаю над мобильным Яндекс Диском — это проект с тысячами тест-кейсов, который развивается уже тринадцатый год. 

Погружение в продукт и новую команду — непростая задача для новичка, но нам удалось выстроить безболезненную адаптацию. В статье поделюсь практиками в команде QA, которые помогли нам за последние четыре года успешно адаптировать новичков (с оттоком 0% за 4 года)

• Спроектировали.
• Разработали.
• Протестировали.
• Начинаем проверять работающий продукт на перформанс.
• Традиционный итог — перформанса не хватает, надо всё переделывать.

Привет!

Меня зовут Андрей и я руковожу IT-подразделением. Около 5 последних лет я работаю в Яндексе с командами от единиц до сотен инженеров. Так сложилось, что команд я потрогал много и разных: некоторых руководителей от времени перемещают по частям компании и зонам ответственности и я – не исключение.

За свой не самый продолжительный, но очень интенсивный карьерный трек я увидел большое количество разных управленцев. Часть – я вырастил из своих ребят до уровней M1 и M2 (руководителей групп и служб). Часть – нанял. Часть – достались мне в наследство.

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

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

Ну что, поехали?

Как понять, насколько правильно ты оценен, насколько верно оценены люди в твоей команде, соответствует ли оценка приносимой пользе и багажу их знаний и навыков? Стоит ли платить больше за знания, которые в данный момент не применяются и могут никогда не задействоваться? Как правильно оценить опыт? Как не обидеть коллег оценками и сподвигнуть их к саморазвитию, а не переходу в другую компанию? И как не раздуть ФОТ до бесконечности, когда люди открывают охоту за грейдами?

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

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

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

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

Привет! Меня зовут Дима. Я из команды бэкенда Яндекс Телемоста — сервиса для проведения видеовстреч, который входит в Яндекс 360. Перед нами стоит задача не просто предоставить сервис, а предоставить отказоустойчивый и надёжный сервис, который работает 24/7 и обслуживает весь мир.

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

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

Если не читали первую часть, настоятельно рекомендую это сделать, чтобы оставаться в контексте.

Итак, продолжим.

В предыдущей статье по работе с API ресурсами в Laravel была затронута тема изменения бизнес-потребностей в области формирования внешнего вида объекта ответа на запрос к API приложения.

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

Привет! Меня зовут Александр Попов, я tech lead команды маркетплейса 05.ru. Сейчас мы занимаемся бэком маркетплейса и некоторыми другими сервисами на рынке Дагестана. 

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

Всем привет, меня зовут Артемий, я работаю старшим Android-разработчиком в команде пользовательского профиля в RuStore. Мой опыт в индустрии уже 8 лет. За это время я успел поработать в разных проектах и компаниях. У меня был опыт работы в проекте, в котором было свыше 300 модулей и больше 60 Android-разработчиков. Такие условия заставляют задуматься о масштабируемости на принципиально ином уровне.

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

В Laravel есть удобные API ресурсы, с которыми легко и приятно работать в области трансформации данных для ответа на запрос. Но что делать когда возникает необходимость изменить их структуру в соответствии с бизнес-потребностями? Разберёмся вместе!