Проджект качай техничку

Задумываешься о переходе в Fullstack? Вот полный список вопросов с недавнего собеседования в Evrone, чтобы проверить готовность. На сколько вопросов ответили бы? 1. Расскажи, пожалуйста, про реляционные базы данных в целом. 2. Сталкивался ли ты с проблемами, когда нужно было сделать денормализацию или наоборот? (Habr, Clickhouse) У тебя третья нормальная форма, у тебя тяжелая нагрузка на СУБД. Тебе может помочь денормализация или нет? Как именно? 3. Ты раскатываешь новую фичу на тестовый стенд и от этого ложится тестовый стенд. Что будешь делать? 4. Что случилось с базой? Накатились миграции. База в изменённом состоянии — как понять что произошло и как реанимировать? (Habr) 5. Откатили миграцию, всё ожило. Фичу надо выкатить — что будешь делать дальше, если просто накатить снова, всё повторится? 6. Ты выяснил через EXPLAIN ANALYZE, что у тебя неоптимальные запросы. Какие наиболее частые причины неоптимальности запросов? 7. Чем JSON и JSONB отличаются в PostgreSQL? 8. JSONB имеет бинарный формат. Что это позволяет сделать конкретно по столбцу? 9. Агрегирующие функции (SUM, COUNT и т.д.) — где их можно использовать в SQL-запросе? В чём разница между WHERE и HAVING при использовании агрегирующих функций? 10. Деплоишь код, с базой всё в порядке, процессор не загружен, но запросы через REST API выполняются последовательно, как будто один за одним. Что может быть не так с конфигурацией подключения к БД? 11. Node.js однопоточная или нет? Сколько потоков может занять исполняемый файл Node.js и почему? Что такое libuv и как он связан с event loop? 12. Как ты понимаешь асинхронность в Node.js? Что такое microtask queue и macrotask queue? 13. Можно ли зависнуть Node.js со стороны JavaScript/V8, не используя бесконечный цикл while(true)? Как сделать так, чтобы очередь промисов никогда не опустела? 14. TypeScript: что такое Omit и Pick? В чём разница между union и intersection типами? Что произойдёт если передать intersection тип в Omit? 15. В чём разница между interface и type в TypeScript? Зачем нужны интерфейсы если есть типы и наоборот? 16. Для чего нужен абстрактный класс? Что произойдёт если разработчик напишет ts-ignore и не реализует методы абстрактного класса? 17. Микросервисы: как реализовывать распределённые транзакции через несколько микросервисов с возможностью отката? Что такое Saga и Outbox паттерны? Я сохранила точный порядок вопросов и формулировки, в которых они задавались. Если нужно подготовиться к собеседованиям на фронт/фулстек, и быть готовым защитить теорию на сложных и незнакомых темах на собеседовании, пиши @BobryshevaAnna Я подготовлю тебя к теории и задачам, буду сопровождать  на новой работе.

🗣 А вы помните RICE, ICE, MoSCoW?! Привет! Сегодня хочу поделиться свежим кейсом с одного собеседования. Я, Анна Бобрышева, задавала Татьяне классический управленческий вопрос: — У вас одна команда, один бэклог и две задачи по 2 недели каждая. Первую принёс начальник с топами, вторую — менеджер по продажам с датой 07.07.2027. Что берёте первой и на основании чего? --- 💡 Что произошло дальше Татьяна начала отвечать интуитивно, «на пальцах». Она честно призналась, что не помнит деталей фреймворков (важность, экономика, скорость), и попыталась избежать чёткого выбора. Я удивилась и сама рассказала ей про RICE, ICE, MoSCoW — про взвешенную оценку, ценность и срочность. --- 📝 Почему это важно На интервью вас никто не просит заучивать фреймворки наизусть. Но когда вы не можете структурировать свой ответ, это сразу заметно. В отличие от проджектов с их ежедневными коммуникациями, аналитикам, архитекторам и разработчикам особенно нужно тренировать диалоговый формат — чтобы в стрессовой ситуации вы опирались не на шпаргалку, а на готовую модель мышления. --- 👥 Чем помог фреймворк После моего пояснения Татьяна взяла паузу и выбрала первую задачу — как стратегическую, с поддержкой топов. Вторую она отложила, запросив у продажников бизнес-обоснование и метрики. Это и есть системный подход: не «кто громче крикнул», а «какой вес у задачи для компании». --- ✅ Вывод для вас Если вы готовитесь к собеседованию — не просто читайте определения. Берите кейсы, проговаривайте их вслух, просите друзей или коллег задавать вам каверзные вопросы. Тренируйте диалог, а не монолог. И да, держите в голове хотя бы пару фреймворков — они реально спасают, когда нужно быстро принять решение. И если вы чувствуете, что теория есть, а в живом диалоге теряетесь — на моих персональных консультациях мы разбираем такие кейсы пошагово, прорабатываем именно ваши слабые места и доводим уверенность до автоматизма. Приходите — помогу собрать ваш личный инструментарий, который не вылетит из головы в самый ответственный момент. --- ❓ А вы помните, чем RICE отличается от ICE? Или в бою пользуетесь только здравым смыслом? Поделитесь в комментариях — был ли у вас случай, когда знание фреймворка выручило на интервью или в работе? --- Inst | YouTube | Вк | MAX #собеседование #подготовка_к_интервью #фреймворки #RICE #ICE #MoSCoW #управление_приоритетами

🗣 Шпаргалки на собеседовании: текст или диалог? Привет! Сегодня хочу поговорить про тренировку говорения. Мы говорили про подготовку к интервью с моей студенткой и задались таким интересным вопросом: вот когда мы готовимся к интервью, когда у нас есть какие-то там шпаргалки, а еще некоторые делают, такие специальные файлики с тремя вариантами рассказа о себе, другие специально под каждое собеседование готовят текст с перепаковкой опыта, буквально под каждую конкретную вакансию!, заранее что-то готовят, насколько это сильно может помочь нам на интервью, --- 💡 Что важно понять про интервью теоретически это, конечно, может помочь нам, но тут есть такой момент все-таки любое интервью, это некоторый танец (и хорошо еще, если парный, а то и коллективный. И так у нас балет, в котором, мы занимаемся постоянным поиском ответов в процессе нашей беседы, тут, знаете, что еще важно! Как можно раньше узнать ответ на вопрос, это вы бросаете партнершу вниз или вы эта партнерша, которую бросают вниз с поддержки. --- 📝 Шпаргалка vs тезисы Короче, если вы читаете с экрана шпаргалку, то это будет довольно заметно, а если тезисы то, это уже лучше, поэтому нужно тренироваться, много, разговаривать много вести диалог. --- 👥 Кому тренироваться особенно важно Обычно, если мы говорим про проджектов, то с этим больших проблем нет, потому что, если вы проджект не только что вышедший на рынок, у вас уже есть опыт работы, а опыт работы проджекта предполагает огромное количество коммуникаций со стейкхолдерами, с внутренними заказчиками и с соседними отделами. Это такое количество коммуникации, что человек диалоги уже умеет вести идеально, с тезисами и без тезисов, поэтому к прожектам это относится в меньшей степени, а вот если мы говорим про системных аналитиков, если мы говорим про архитекторов, если мы говорим про разработчиков, то вот вам ребята нужно обязательно тренировать диалоги, вам нужно как можно больше проходить тренировочных интервью, --- ✅ Вывод идите к своим друзьям, просите зачитать список вопросов. Просите там вашу девушку, чтобы она зачитала вам какой-нибудь список вопросов, тренируйте диалоги-это прекрасный опыт перед собеседованием. --- ❓ А вы готовите полные тексты или только тезисы? Или вообще импровизируете? Поделитесь в комментариях своим опытом — бывало, что шпаргалка подводила? --- Inst | YouTube | Вк | MAX #собеседование #подготовка_к_интервью #навыки_переговоров #развитие_softskills

Доступна запись вчерашнего собеседования на руководителя проектов, личную часть не записывала, записывала общие вопросы и разбор. https://disk.yandex.ru/i/ZY_eRBL_yEWIcw

Приглашаю всех сегодня посмотреть МОК собеседование Руководителя проекта, которое я буду проводить в карьерной группе. Сегодня вечером в 19:00 Будем миролюбивое собеседование проводить, так как человек давно не собеседовался Подключайтесь по ссылке в 19:00 https://telemost.yandex.ru/j/51177777001562

И так на собеседовании вам задали вопрос про виды архитектуры, вы конечно назвали: Монолит, Микросервисы, Сервис ориентированную архитектуру и событийную архитектуру. Дальше, у вас спрашивают либо просто про Микросервисную архитектуру, либо про отличия между Микросервисной архитектурой и Монолитом. Главное постараться максимально системно ответить на этот вопрос, отвечайте в первую очередь про то, что: · каждая бизнес-функция вынесена в отдельный сервис, · у каждого сервиса своя кодовая база, · каждый сервис публикуется и исполняется отдельно (свой конвейер, свой деплой, своё масштабирование), · сервисы общаются между собой по сети (HTTP/gRPC/очереди). Микросервисы — это всегда про бэкенд. Фронтенд здесь не меняет сути. Вы можете иметь один SPA‑фронт, который стучится в 10 микросервисов через API, — архитектура бэкенда остаётся микросервисной.

Что важно для собеседования : · Фронт и бэк внутри одного приложения — это не отдельный сервис, а часть монолита, не смотря на то, что у фронта свой собственный Фреймворк. · Публикация происходит единым пакетом (одна сборка, один деплой). · Одного разработчика хватит, чтобы доработать и кнопку на фронте, и логику оплаты в бэке — это и есть признак такого монолита. · Если фронт выделен в отдельный проект (React + Nginx + отдельный деплой) — это всё ещё монолит со стороны бэкенда, но уже не «внутри одного фреймворка». В ответе на собеседовании важно различать эти два случая.

А мы продолжим, про Модель и Монолит. Я писала про Модель, которую вы должны уметь нарисовать на бумажке так, чтобы вас понимали, и нотация нам не важна. Что надо изобразить, если вас попросили нарисовать систему с архитектурой монолит, рисуем примерно такую схему, где накидываем кучу разных модулей и обязательно выставляем наружу все возможные интеграции и БД. Но может конечно оказаться, что у вас отдельно существует фронтэнд, со своим собственным фреймворком в монолите, как вы думаете, куда надо поместить изображение такого фронтэнда внутрь или наружу системы?

Проектирование распределенных систем и понимание интеграций — вот что чаще всего вызывает сложности у кандидатов на собеседованиях. Самый первый вопрос по архитектуре, который ставит людей на собеседовании в ступор, это "Какие архитектуры вы знаете?" Правильный ответ на этот вопрос включает в себя четыре архитектуры, это монолитная архитектура, микросервисная архитектура, сервис ориентированная архитектура и событийная архитектура. Задать этот вопрос могут по разному "С какими видами архитектуры вы работаете?" "Какие стили проектирования вы знаете?" Но, конечно же, если вы просто перечислите четыре базовых подхода к проектированию архитектуры, на этом вопрос не заканчивается. Как правильно объяснить в чем суть каждого подхода. Поговорим про Монолит, самое важное, что нужно ответить на собеседовании про МОНОЛИТ, то что это в первую очередь описывает бэк, мы говорим монолит подразумеваем, что у нашего бэка есть единая кодовая база, публикация бэка происходит единым пакетом поставки, без разделения на части как при публикации, так и при исполнении. Говорить что у нас приложение монолит, мы можем и в том случае, если у нас фрон отделен от бэка, но бэк представляет единое целое, и при использовании нашим приложением бэка одной БД, и даже в случае, если мы используем выделенные БД для медленных данных, выделенную БД для перс данных, все равно приложение будет монолит. По виду архитектуры нашего бэка. Это важно понимать, при ответе на вопрос. Так как вам могут задавать дополнительные вопросы, про системы с которыми вы будете взаимодействовать, это те же Базы данных, например. Чтобы ответить на этот вопрос корректно, надо определять границы области проектирования, изолироваться от БД и Фреймворков для фронта. Бывают приложения в которых фронтэнд и бэкенд объединены в единую кодовую базу. Как правило в таком случае мы ставим задачу на одного разработчика и для доработки функций бэкэнда так и на доработку функций фронтэнда. Теперь поговорим про внутреннюю архитектуру Монолита, конечно же МОНОЛИТ тоже внутри делится на модули, это могут быть такие модули как модуль управления жизненным циклом заказа, модуль оплаты, модуль взаимодействия с базой данных, модуль слушателя и обработчика событий, модуль шины обмена и оркестрации работы других модулей. По сути монолит ничем не уступает другим архитектура по систематизированности, стройности данных внутри приложения, его основной минус в том, что его не возможно поддерживать по частям и не возможно управлять им по частям, как, например в реализации сервисов. Хочешь проходить собеседования без ступора и уверенно отвечать на любые вопросы по архитектуре? В «Качай техничке» разбираем не только теорию. Реальные кейсы, схемы, разборы подводных камней, но без воды. 👉 Подписывайся: 🚀 Здесь твой скилл растёт с каждым постом. Никакой зубрёжки — только то, что реально спрашивают на собесах. #архитектура #собеседование #монолит #качайтехничку

Мы начинаем МОК собеседование 1С разработчика присоединится можно по ссылке, формат собеседование и разбор вопросов, как на них лучше отвечать. Переходите по ссылке! https://telemost.yandex.ru/j/51177777001562

Модели в аналитике: зачем их много и почему не нужен один язык Аналитику нужны модели для общения с представителями заказчика, разработчиками и тестировщиками. Модель может быть как формальным документом для передачи знаний, так и вспомогательным инструментом для улучшения взаимопонимания участников проекта. Что такое модель? Модель — это упрощенное представление системы или процесса. Внимание сосредоточено на определенных характеристиках, а от всех остальных он абстрагируется. Если воспроизвести абсолютно все характеристики моделируемого объекта, получится не модель, а сам объект. Один объект — много моделей Если модель описывает только определенные характеристики, то один и тот же объект или процесс может быть смоделирован множеством разных способов. Модели могут отличаться: · задачей, для которой создаются; · способом реализации (языком моделирования и инструментом). Это нормально На практике аналитик может построить несколько моделей для одного проекта. Каждая будет отражать только часть информации. И необязательно они будут выполнены в одной среде моделирования с использованием только одной нотации. Не нужно стремиться всё моделировать на одном языке в одном доступном средстве. Для ряда задач вполне подойдут листок, карандаш и ваше умение рисовать понятные собеседнику картинки. Главное Задача аналитика — помочь людям решить их проблемы. Если модель помогает — вы хорошо и профессионально делаете свою работу. Если модель не помогает — вы просто выбрасываете деньги на ветер (обычно чужие). 12 июня в 19:00 разбираем вопросы для собеседований системного аналитика в телемосте https://telemost.yandex.ru/j/51177777001562

«Я не знаю» — три слова, которые спасут собеседование Бывает так, что интервьюер задаёт вопрос, и вы не представляете, что на него ответить. Что первое приходит на ум в такой ситуации: — попробовать отболтаться, уйти в туманные рассуждения, — уточнить вопрос так, чтобы интервьюер уточнил ответ на свой вопрос сам, собственно переспросить «а что вы имеете в виду?», тут можно перефразировать метод пять почему в метод пять уточнений по вопросу, — начать ссылаться на другой как будто бы такой же кейс, но уже известный вам, про «мы в компании не так делали». Спойлер: всё это мгновенно считывается, как неподготовленность. Или, что еще хуже, могут подумать, что вы врете или выдумываете. Как можно выйти из сложившейся ситуации: Неожиданное решение, прямо сказать: «Я не знаю. Но я знаю, где искать, и как бы я это делал». Разница между джуном и синьором — не в объёме знаний. А в том, как человек ведёт себя на границе «не знаю». Пример: «Честно, с Redis Cluster я не работал. Но я читал про consistent hashing и видел схему с sentinel'ами. Если бы мне поставили задачу — начал бы с доклада на хабре и набросал бы прототип за день». Интервьюеру не нужен ходячий справочник. Ему нужен человек, который находит решение. Задайте себе перед собеседованием три вопроса: 1. Где у меня сейчас явные пробелы? 2. Как я их закрою за неделю? 3. Что я скажу, если спросят про то, что закрыть не успел? П.3 важнее всего. Заготовьте 2–3 фразы, чтобы в них была выражена ваша уверенная позиция решить "любую" задачу. P.S. не могу удержаться и не позвать вас к себе на консультацию, пишите в личку @Bobryshevaanna

Такая ситуация: клиент нажал «восстановить пароль», а почтовик лег на 5 секунд (ну, бывает, вернул ошибку 500). С большой вероятностью клиент получит дубль письма. Так как фронт дернул запрос еще раз... И вуаля - пользователь получает два письма. А если это код подтверждения заказа на 100500$? В одном коде цифры, в другом - другие. Ад, хаос, потерянные нервы. Система-отправитель (клиент email-сервиса) обязана генерировать уникальный идентификатор message_id для каждого бизнес-события (например, сброс пароля, подтверждение заказа). Email-сервис должен реализовать идемпотентную обработку: при повторном запросе с тем же message_id (в т.ч. после ошибки 5xx) не отправлять письмо повторно, а возвращать 200 OK. Проблема в том, что сервис отправки не отличает повтор от нового действия. А идемпотентный ключ - единственный способ сказать: "эй, это тот же самый запрос, не делай ничего второй раз". Email-сервис должен поддерживать идемпотентность по уникальному ключу (message_id) с хранением минимум 24 часа. При повторе запроса с тем же ключом - вернуть успех без повторной отправки.

Помните, я звала вас на чай/кофе в субботу? Так вот, присоединяйтесь! 🔥 Сегодня в 20:00 встречаемся в прямом эфире. Без галстуков. Почему стоит зайти именно сегодня? У меня для вас эксклюзив в прямом эфире: ✅ Я только что прошла собеседование в Альфа Банк. Расскажу всё, как на духу: какие вопросы реально задают, где подловили, а где я сама удивила ответами. Инсайты для тех, кто целится в крупный IT / Fintech. ✅ Разберем ваши ситуации. Кто сейчас в поиске или боится ступить на первое собеседование — вам точно ко мне. ✅ И, конечно, нетворкинг: обменяемся контактами, я лично всех услышу. Давно хотела собрать вас в одной «комнате». 🗓 Сегодня, 20:00 📍 Ссылка на телемост: https://telemost.yandex.ru/j/83844373455785 Кому залетать: — Тем, кто готовится к техсобеседованиям (мои ученики знают, я не жалею деталей). — Кто просто хочет живого общения с ИТ-директором без пафоса. — Кто планирует свое лето. 💬 Никаких записей потом не выложу. Только здесь и сейчас. P.S. Унас нетворк терапия, а не лекция. Жду!

Коллеги, я очень по всем соскучилась! Планирую регулярно писать сюда полезное про техподготовку к собеседованиям, ИТ и лайфхаки по трудоустройству. Последние полгода были насыщенными: по-прежнему работаю ИТ-директором, веду два проекта внедрения 1С, пишу три сайта. Но главное — выпустились 5 учеников с курса наставничества. Виктория учила Python, Дарья и Влада — 1С. На сопровождении работали со Станиславом, Надеждой и Романом. Сейчас работаем с Дмитрием. Я шучу, что пора собирать свой бигтех — уже есть все роли, подготовленные для себя. Однажды так и сделаю: позову всех и соберу команду мечты! А пока предлагаю поднять настроение тёплым летним вечером и собраться на чай, кофе. В эту субботу вечером, когда все вернутся с пляжа, доедут до дач и освободят голову от трудовых будней, поговорим в тёплой ИТ-среде про лето и ваши планы.

Сижу, читаю новости, а OpenAI вчера выложил на гитхаб штуку под названием Symphony. (Любые совпадения названий случайны) И меня это зацепило. Не потому что я фанат OpenAI, а потому что это прям хорошая иллюстрация того, куда вообще катится наша индустрия. Смотрите, суть: Symphony - это такая прослойка, которая сама смотрит в трекер задач (Linear), находит там задачи, создает под каждую отдельное окружение, запускает туда кодинг-агента (Codex) и гоняет его по кругу, пока задача не будет сделана. Агент потом приносит доказательства - вот CI прошел, вот PR проверен, вот видео с тем, что получилось. Разработчику остается только нажать "принять". Но самое интересное не это. Самое интересное - как они это сделали. Они выложили не просто программу, а спецификацию. И сказали: ребят, вот как это должно работать, а реализацию пишите сами, на чем хотите. Хотите на Python - вперед, хотите на Go - пожалуйста. Даже прикололись: "Можете попросить вашего любимого агента собрать Symphony по этой спецификации". Т.е. агент пишет оркестратора для агентов. Мета, да? И второй момент - они сделали это на Elixir. А Elixir - это язык, который создан для того, чтобы управлять тысячами параллельных процессов, следить за ними, перезапускать если упали, обновлять код на лету без остановки системы. Это такой намек: они видят будущее, где таких агентов будут работать одновременно тысячи. О чем это говорит? На мой взгляд, мы переходим от эпохи "инструментов для разработчика" к эпохе "инструментов для управления". Раньше мы думали: как помочь программисту писать код быстрее. Теперь думаем: как сделать так, чтобы программист вообще не писал код, а только смотрел, как его пишут другие. Symphony - это такой "менеджер в коробке". Который сам распределяет задачи между агентами, сам проверяет результат, сам отчитывается. И вот мне стало интересно: а как бы вы такую штуку к себе в процессы встраивали? С чего бы начали?

Полностью согласн в связке приложений

🧪 КАК НАВЫКИ АНАЛИТИКА ПРОКАЧИВАЮТ ВСЮ КОМАНДУ Современный IT-мир движется к мультиролевым командам. Аналитик думает как тестировщик, проджект умеет читать данные, разработчик понимает бизнес. Разбираем на примере магазина «Мобильные гаджеты», как это работает в жизни. 🐛 КЕЙС 1. Аналитик → QA: «Валидация даты рождения» Контекст: В нашем магазине при регистрации пользователь указывает дату рождения для персональных скидок. Ситуация: В ТЗ написано: «Дата рождения в формате ДД.ММ.ГГГГ». Разработчик сделал поле, QA покликал — всё работает. Через месяц маркетолог не может сделать рассылку: в базе данных 12.12.1990, 12/12/1990, 1990-12-12 и даже «12 декабря 1990». Что сделал бы хороший аналитик: Заложил тестируемую логику прямо в спецификацию. Acceptance Criteria (критерии приемки): Поле даты рождения принимает только цифры и точки в маске «ДД.ММ.ГГГГ» При вводе 12/12/1990 — ошибка «Неверный формат. Используйте ДД.ММ.ГГГГ» В базе данных поле birth_date — тип DATE Код автотеста (пример в спецификации): def test_birth_date_format_invalid_input(): """API возвращает 400 при неверном формате даты""" payload = { "birth_date": "12/12/1990", # Нарушаем формат "phone": "+79991112233" } response = client.post("/api/v1/users/profile", json=payload) # 400 Bad Request — клиент прислал некорректные данные assert response.status_code == 400 # Проверяем, что ошибка понятная error = response.json() assert "формат" in error["message"].lower() assert "birth_date" in str(error["details"]) 🔍 Почему 400, а не 404? — 404 Not Found — ресурс не найден (нет такого URL) — 400 Bad Request — сервер не может обработать запрос из-за ошибки клиента 📊 КЕЙС 2. Аналитик → Разработка: «Акция на чехлы» Контекст: Акция «Купи 3 чехла — третий в подарок (скидка 100%)». Ситуация: Фронт работает, тесты зеленые. На проде в 5% заказов скидка уходит на первый товар, а не на третий. Решение: Аналитик написал SQL-запрос для проверки еще на этапе тестирования. SELECT order_id, SUM(price) as total_price, SUM(discount_amount) as total_discount, CASE WHEN SUM(discount_amount) = MIN(price) THEN 'Ошибка: скидка на дешевый, а не на третий' END as check_result FROM order_items WHERE product_category = 'cases' -- Только чехлы GROUP BY order_id HAVING COUNT(*) >= 3; Результат: Баг найден до массовых продаж, логика исправлена. 🚀 КЕЙС 3. PM → Данные: «Почему упали продажи iPhone?» Контекст: Обновили фильтр в каталоге, добавили выбор по годам. Упала конверсия в категории iPhone. Ситуация: Product Owner в панике: «Срочно откатывайте!». Команда начинает расследование, которое может занять дни. Решение: Проджект с аналитическим мышлением прямо на дейли пишет SQL. -- Какие фильтры выбирают пользователи на проблемной странице? SELECT filter_name, filter_value, COUNT(*) as usage_count FROM user_activity_log WHERE page = '/catalog/smartphones' AND event_type = 'filter_apply' AND date = CURRENT_DATE GROUP BY filter_name, filter_value ORDER BY usage_count DESC LIMIT 5; Что нашли: Пользователи массово выбирают «Год выпуска: 2020», но фильтр не применяется к iPhone из-за бага в интерфейсе. Итог: Вместо отката всего функционала — точечный фикс за 2 часа.

Channel photo updated