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

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

На все эти вопросы ответил frontend-разработчик Виталий Старов на конференции FrontendConf 2021. Он рассказал о серверном рендеринге на примере приложения SuperJob. Читайте под катом, как SuperJob пришли к своей реализации серверного рендеринга, узнав по пути много интересного. Узнаете, когда хорош SSR и как он работает, из чего он устроен, чем может быть полезен и кому.  

Иногда бывает довольно сложно сэкономить на Spot Instance Amazon Web Services (AWS). Не стоит забывать, что по сути это — аукцион. Цены хоть и не меняются так же резко, как на биржах, тем не менее могут расти, пока не достигнут ondemand. Бывает, что такое продолжается не день и не два, а до нескольких месяцев, что приводит к повышению расходов вдвое на обычные ресурсы.

Как не попасть в ситуацию, когда, например, в ноябре всё прошло отлично, а в декабре из-за праздничного ажиотажа прайс удвоился, и вы получили не только дорогую систему, а ещё и с прерыванием? Давайте разберем причины, почему так происходит. Для этого рассмотрим стратегии распределения Spot Instance и поймем, как можно использовать модуль Terraform без всех этих проблем и при этом еще и сэкономить. В этом нам поможет инженер по облачным сервисам и архитектор AWS Владимир Самойлов, участник сообщества FivexL.

Как выглядит процесс принятия решений в ваших командах? Если вам нужно принять совместное, устраивающее всех, решение, то как вы достигаете консенсуса? С какими сложностями сталкиваетесь? Если у вас есть молчуны, то решение принимают самые громкие?

Меня зовут Александра Баптизманская, мы с Евгенией Чумачковой и Оксаной Сливинской работаем Agile-коучами, у нас есть небольшая компания Co-Actors. Сегодня мы научим вас, как при помощи довольно простых фасилитационных техник помочь принять решение группе — не единолично, не демократическим способом и не методом «Два лида договорились». Расскажем, как вовлечь всю группу и провести ее через этот процесс — от генерации идей через споры-обсуждения к выбору решения, которое устроит всех, и достичь консенсуса.

Человеческий мозг обычно лучше воспринимает информацию из изображений, чем из текстов. И в инструментах, подобных Flame Graph, этот принцип блестяще реализован. Поэтому в Percona его используют в рамках работы группы поддержки. Чаще всего в тех случаях, когда нужно получить всестороннее представление о том, что и как долго проделывает MySQL. Так можно лучше понять, какие операции стоят за конкретной рабочей нагрузкой и каким образом лучше исправлять возникающие проблемы. И это можно использовать и для оптимизации, и для устранения неполадок.

Давайте воспользуемся их опытом и разберемся, откуда брать и как подготавливать образцы для визуализации данных. А после этого — как из них генерировать Flame Graph и как с этим работать.

Наша объединенная конференция DevOps&TechLead 2022 года уже очень скоро! И пока мы ее вовсю готовим, давайте вспомним, как закончились конференции в прошлом году — и какие доклады вам понравились. Если вы уже участвовали в наших конференциях DevOps&TechLead — это будет для вас как небольшое путешествие в прошлое, где мы воссоздадим в памяти атмосферу и эмоции. А если вы всё пропустили, то сегодня вы сможете представить, как там было. Поехали!

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

Привет! На связи Олег Уткин из отдела архитектуры систем хранения данных Tarantool. Я хочу рассказать, как в ходе проекта для Московской биржи мы консолидировали потоки данных из разных торговых систем и наладили их доставку клиентам. По пути мы собрали много граблей и сделали несколько интересных выводов, которыми я далее поделюсь.

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

Меня зовут Виталий Шароватов, я работал в mail.ru, badoo, raiffeisen, qlean, rocketbank, сейчас работаю в Qase. 13 лет писал на JavaScript, а сейчас занимаюсь просветительской работой, менторю тимлидов и читаю лекции. Так что, мне есть чем с вами поделиться.

Это маленькая, но полезная ретроспектива двух профессиональных конференций по интеграции процессов разработки, тестирования и эксплуатации. До совместного мероприятия DevOps&TechLead Conf 2022 осталась всего пара месяцев, поэтому самое время восстановить в памяти то, что было раньше.

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

Меня зовут Анжелика Федько, я успела поработать с базой знаний с разных сторон. Например, пока была инженером технической поддержки, занималась её наполнением, созданием новых статей и актуализацией. Когда стала тимлидом, взяла на себя уже более стратегические проекты, которые нацелены не на улучшение конкретной статьи, а на базу знаний в целом. Таким образом, за 6 лет работы с базой знаний я успела рассмотреть ее с разных сторон.

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

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

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

Прежде, чем стать системным архитектором, я успел побывать разработчиком и тимлидом. И моя работа всегда была неразрывно связана с людьми, технологиями и процессами. В этой статье я хочу рассказать, как благодаря оптимизации процессов мы ускорили time-to-market для IT-систем нашего отдела.

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

На старте было просто: связаться с нами можно было только через почту. Входящим ящиком был IMAP, исходящим — SaaS сервис по отправке почты, забрать письма с которого было то еще приключение. Мы смотрели на заголовки и соединяли письма в цепочки, как в любом почтовике: Gmail, Outlook. В таком виде передавали операторам. 

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

Так появился проект линковка.

Часто пользователи рассказывают о сбое базы данных по вине Out Of Memory Killer. Он завершает процессы PostgreSQL и остается причиной большинства отказов этой БД. Память на хост-компьютере может закончиться по нескольким причинам. Наиболее распространены из них четыре. Во-первых, может быть плохо настроена память на хост-компьютере. Во-вторых, могут быть ограничения глобальной переменной work_mem. Например, если у вас 32Гб RAM и work_mem=1Гб, то больше 32 соединений вы никогда не запустите. Каждое соединение PostgreSQL будет выделять этот размер памяти.

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

Представляем вам перевод статьи от Jobin Augustine, который работает в Percona старшим инженером службы поддержки. Более 20-лет он был консультантом, архитектором, администратором и инструктором по PostgreSQL, Oracle и другим технологиям баз данных. Сегодня поговорим о том, как можно защититься от OOM с помощью HugePages и разберем насколько они важны и почему нужны.

В мире огромное количество людей, которые стали руководителями, а потом перехотели ими быть — в чем дело?

Когда мы молодые и амбициозные, то готовы брать все, что дают и радуемся любому повышению: «Вау, челлендж! Сейчас всем докажу! Я хочу быть руководителем, хочу власти и успеха!». На самом деле, мы не всегда понимаем, куда нас несет течение, что нас ждет на следующей ступени, на которую мы шагаем.

Я сделала короткий опрос в сообществе менторов по этой проблеме. Оказалось, что 16 из 22 менторов сталкивались с запросом «Как мне вернуться в специалисты?».

Меня зовут, Марина Перескокова, я уже 15 лет в IT, 10 из них проработала в Яндексе. У меня и моих знакомых тоже случались подобные проблемы. Давайте разберем 8 самых распространенных причин, почему руководитель больше не хочет быть руководителем.

В своем докладе на конференции TestDriven Conf 2022 Станислав Васенков предлагает за минуту создать из ручного теста проект с автотестами в боевой инфраструктуре. О том, как разрабатывался генератор, можно узнать из интервью.

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

Однажды мне повезло попасть на запредельно крутой митап. Сотрудники одной компании объединились вокруг своего интереса и с завидным постоянством встречались для его обсуждения. У них было всё серьёзно, для каждой встречи собирали статистику, сколько человек к ним присоединилось, а сколько — пришло, но по какой-то причине ушло и не вернулось. На несколько месяцев вперед у них были расписаны темы, о чем поговорить. В общем, они были великолепны!

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

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

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

Вы не одни. В сегодняшней статье Юлия Белозерова, которая выгорала уже полтора раза, решила поделиться своим опытом. Последние 10 лет она занималась управлением проектами в аутсорсинге, в продуктовых компаниях (ex-Yandex, ex-Epam, ex-Booking.com). Юля не врач, не терапевт, не психолог и не профессионал по выгоранию. Это взгляд выжившего.

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

Хотелось бы рассказать про те, что доказали у нас свою эффективность. Сегодня это будет стратегическое верхнеуровневое проектирование — о том, как разрабатывать программы с точки зрения моделей и требований. А в следующей части я расскажу про практики для работы с кодом и архитектурой, то есть более приближенные к разработке. Надеюсь, что вы сможете ими воспользоваться, а если вы еще не используете DDD у себя в проектах, то попробуете.

Tarantool, как известно, поддерживает любой язык, который совместим с C и компилируется в машинный код. В том числе есть возможность реализации хранимых функций и модулей на Lua и C. Тем не менее, уже в двух своих проектах мы использовали Rust (в одном полностью перенесли Lua-код на Rust) и получили 5-кратное увеличение производительности по сравнению с Lua и сопоставимый результат, который дает по производительности C.

Когда тренер Ливерпуля Юрген Клопп, который сделал команду чемпионом Англии и победителем Лиги Чемпионов, только появился в команде, то в первую очередь он встретился с начальником академии Ливерпуля. Почему?  Потому что Клопп, как тимлид, знает, кто будет играть у него в команде и какие требования к ним он предъявляет. Самым важным для него было рассказать об этом начальнику академии, чтобы тот знал, как воспитывать игроков для Клоппа.

А как, думаете, с этим обстоит дело в мире SW development? Мы с завидным постоянством пытаемся отдать работу с молодыми специалистами — ребятами, которые учатся в университетах —  на откуп рекрутерам. И считаем, что только они должны заниматься сотрудничеством с вузами.

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

Для таргетинга мы в Ozon используем сегменты, в которые группируем пользователей по интересам. Интересы могут быть определены через систему трекинга событий. Последние в свою очередь формируются в процессе взаимодействия пользователя с маркетплейсом Ozon. На основе сегментов мы отправляем нотификации, рассылаем письма, показываем рекомендации, баннеры, страницы с товарами и цены на товары, участвующие в маркетинговых акциях. В принципе, на сегменты можно завязать любую механику. Мы даже А/В тесты иногда проводим с ними.

Первоначально сегменты создавались вручную: поступал запрос от заказчика, после чего проводилась аналитическая работа по сбору требований. Количество заявок на создание сегментов со временем только увеличивалось. Чтобы автоматизировать процесс создания сегментов мы решили сделать конструктор сегментов для DMP — Data Management Platform. Это относительно молодой проект, ему чуть больше двух лет, но он полностью себя оправдал. Сегодня расскажу вам о нашем опыте. Меня зовут Евгений Чмель, и я руковожу командой DMP & CDP.