Нулевой километр (Хекслет)

Hexlet (00:00.43)
Всем привет, на связи Хекслет, с вами Александр Усков и в нашей виртуальной студии сегодня Кирилл Евсеенко, CTO компании Start, онлайн-кинотеатр.

Hexlet (00:18.542)
Кирилл, привет. Привет. Ну, расскажи, пожалуйста, в двух словах для тех, кто выполнил инфопространство на последние н лет. Что за компания Start? Компания Start – онлайн-кин-театр. Один из немногих на российском рынке. Мы предоставляем пользователям возможность смотреть наши оригинальные фильмы сериалы, которые в первую очередь производит наша собственная студия, продакшн. Это наш основной драйвер и пользователи.

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

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

бренды и вендеры, которых мы можем дотянуться. Есть более хитрые устройства типа STB приставок, року делаем приложение, возможно сделать приложение для Xbox, может быть когда-нибудь для PS5 даже сделаем. Звучит очень-очень обширно. Если опять же можно как-то обобщить, на каких вообще технологиях все это работает? То только всего? Есть какой-то у такой центральный стэк?

Ну стэк различен для каждого из направлений. Вся у нас разработка in-house, нас нет никакой заказной разработки, все сделаем самостоятельно, внутренней in-house командой. По каждому из направлений у нас небольшая команда, которая занимается этим направлением и стэк определяется, собственно, этим направлением. То есть для front-end свой стэк, для back-end свой стэк, для дата warehouse свой стэк и так далее.

Hexlet (02:39.214)
Если чуть-чуть поподробнее можно, да. Могу расширить, да. Бэк энд у нас на питоне на го, это основной стэк. Используем активно докер, все крутится в кубере. Из фреймворков используется активно фласк, используется фаст таппи. Используем граф куэль, рест таппи. Что еще? Основные базы это пост гресса монга.

внутри. Иктивно используем Revit, используем Kafka, то есть довольно стандартный стэк на самом деле, технологий, который используется во многих компаниях. На фронт-энде у нас React, на фронт-энде у нас Jazz, на фронт-энде у нас Next.js используется. Что касается работы с видео, используем стандартные библиотеки и на основе их делаем свои решения типа Player и так далее.

мобильное устройство используем нативные технологии, то есть мы не пошли в сторону использования...

React Native и вот всяких подобных историй. Да, используем нативные технологии. Соответственно, Android на Kotlin, iOS на Swift. Пишем под них, потому что нам очень важно использовать нативные инструменты и нативные вещи, которые представляет сама платформа. Это очень важно, потому что пользователи привыкли этим пользоваться в рамках своей платформы. На смартах у нас HTML5.

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

Hexlet (04:28.173)
Что еще? Внутри DWHA скрипты на питоне есть самописные системы, которые мы используем для реализации тех или иных вещей, которые нам необходимы для работы. Кавка, наверное, да, едно там, полагаю. Кавка, да, есть кавка. Что касается аналитики, сбор у нас происходит в клик. Что касается инфраструктуры, которую мы тоже отвечаем, это bar metal, то есть мы берем...

голые сервера и на них все разворачиваем свой куберкластер, докер и вот это все. И сейчас на ZUSHIT максимально все знакомо, как бы я сразу предполагаю куда можно дальше копнуть, по частям додвинемся. Начнем с веба, веб самая интересная лично для меня. Правильно я понимаю, что у вас вас Next.js, то общем вопросов там каких-то серверного рендеринга у вас не стоит, делается вот этим самым Next.js. У нас есть надо.

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

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

сторонние решения, как сторонние, там видео.js например на вебе мы использовали, в других устройствах например там в андроиде там стандартно де-факто является экзоплеер например, но вот например касаемо веба мы просто используем библиотеки HLS.js, Dash.js и накручиваем на них уже визуал, то есть мы используем базовые какие-то вещи

Hexlet (06:44.365)
В какой-то момент пошли просто, так продуктово не смогли на базе Video.js, который тогда использовался, сделать те вещи, которые от нас требовал бизнес-продукт, и посчитали, что проще и дешевле в будущем будет сделать кастомное решение и, соответственно, его поддерживать. То есть у нас сейчас свой самописный плеер, который мы продолжаем развивать и можем с ним что угодно делать. Позвольте спросить...

Сейчас, в прошедшее время, насколько это решение кажется оправданным? Кажется оправданным, да. Да, кажется оправданным. Плюс там есть внешние решения, которые все-таки стоят денег. И с учетом текущей ситуации для российской компании, это могло бы быть дополнительной проблемой. Тут понимаю. Но в то же время мне как человеку, некоторым образом, задействовав еще в найме, очень любопытно, насколько вообще легко найти разработчиков, кто может это все блестить и воспользоваться. Ведь это, скажем так,

Не совсем стандартный фронт-энд, да? То есть там уже знание вверстки тебе вообще не нужно, по большому счету. Знание там JavaScriptа столько, поскольку очень много специфики именно для видео. Просто еще интересно, как решается кадровый вопрос, чтобы вот такие штуки делать? Ну, наверное, как ты знаешь, что большинство все-таки задач не связаны с такими тонкими, тонкими историями. Большинство задач связаны в первую очередь там с продуктом, а вещи связанные вот с какими-то такими узкими специализациями возникают довольно редко.

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

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

Hexlet (09:12.749)
у нас команда кросс-функциональная. И в зависимости от сложности задачи, от скорости команды у нас выходит так, что функционал с разной скоростью целом появляется на продакшене на разных типов устройств. Для нас это OK. То есть мы не ждем обычно, что давайте доделаем все и потом весь функционал выкатим. То есть это в целом нормально.

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

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

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

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

Hexlet (11:28.461)
многие пользователи предпочитают зайти в браузер мобильный и пользоваться приложением там. Да, для меня это тоже загадка, почему так. Ну, с одной стороны, наверное, я не знаю, кто ли проводил либо исследование, нет, но тоже замечал, что мне, лично для одноиденоразового использования поставить приложение лень. Но если я там подписчик регулярно что-то смотрю, то довольно удивительно, что люди продолжают пользоваться мобильным вебом, в котором есть масса известных проблем. В том числе и с поддержкой устройств. Все верно, да. Поэтому один…

Неназванный онлайн-кин-театр даже на мобильном вебе просто показывает заглушку «Иди сходи в магазин», как бы, и не парится совершенно по этому поводу. Да, знаем таких. Ну, тем интереснее спросить. Наверняка у вас возникали тоже нюансы, связанные с поддержкой мобильного веба на платформах, да? То есть Android и iOS все-таки веб-не-веб, но очень разные, да? Истории с очень статистическими возможностями, проблемами. Как вообще вы к этому подходите? У нас, я считаю, замечательная команда тестирования.

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

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

И, соответственно, когда продуют, говорить, хочу, чтобы у пользователей в полном экране там бюсели мои баннеры», а ему говорят «извините, на iOS не получится». Как вот это вот просто решается вообще? Встречались ли вы с таким? Приходилось ли это решать? Да, конечно, встречались, но по поводу плеера и iOS overlay нам удалось. да, нам удалось. Но не все, да, не все вещи могут быть реализованы. В этом случае у нас в рамках…

Hexlet (13:52.525)
цикла прохождения задачи от ее постановки до реализации, до выкатки в продакшн есть определенные этапы и на этапе постановки задачи в разработку мы проводим во-первых встречу с командой продукта с людьми, которые отвечают за эту постановку задачи, по сути для нас является стеколдером и у нас проводятся груминги внутри разработки

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

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

Такой вопрос очень лично не любопытно. Я честно скажу, не пользователь Start, хотя как бы знаком с некоторым контентом, у вас есть же и вот модель, то есть распространение с рекламной амбицизацией? Нет. Или вас только подписка? Нет. А вообще вас есть какие-то рекламные инструменты, рекламные размещения? Нет. Только с вылоканта. Мы вообще с момента запуска позиционировали, продолжаем позиционировать себя сервисом.

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

Hexlet (16:07.981)
А по 14 февраля подборочка фильмов про любовь и ссылочка там на что-нибудь. Да, я понимаю, о чем ты говоришь. Это уже в сторону продукт-плейсмента, вот. Так как, у нас есть в целом холдинг, да, и в холдинге есть студия, которая, старт-студия, которая производит наши оригинальные проекты. Там есть у них, конечно же, и, по-моему, даже отдельная компания у нас есть внутри холдинга, занимается именно продукт-плейсментом. Это размещение...

каких-то продуктов, либо каких-то брендов внутри сериалов, внутри того, что мы сами производим. Внутри контента, я понял. Да, да, да. Это в том числе может повлиять на то, что мы видим на сервисе. У на моей памяти за 5 лет было две таких интеграции, где мы делали отдельные лендинги для отдельных брендов в части запуска очередного сериала.

очередного оригинального проекта. ладно, тогда не будем сильно углубляться. В пленнинги, мне кажется, вещь понятная. Про тег было бы интересно, конечно, помодить. Ну, видимо, другой раз. Про Smart TV еще поспрашиваю. Многие, мне кажется, не до конца представляют, как вообще работает приложение на телевизорах. Для меня для самого, когда я во все это пришел, было достаточно удивительным открытием, что в большом счет тот же самый frontend с некоторыми нюансами, что у местной мышки вас пульт, соответственно, управление...

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

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

Hexlet (18:27.277)
который позволял нам использовать кросс-платформенность. есть мы в части разных фендеров, у них разные игайды, разные дехи есть, которые ты должен разрабатывать и так далее. Современные фреймворки, они позволяют делать кросс-платформенную историю, при этом учитывая нюанс конкретной платформы. Вот мы одним из таких фреймворков.

используем сейчас. Он называется PyrkML. Мы делаем приложение одно. В зависимости от того, где это приложение запускается, используются какие-то нативные элементы, какие-то базовые классы, необходимые для запуска этого приложения. есть собирается сборки, если необходимо, либо формируется ссылка, которая дается.

либо вендору в большинстве случаев для размещения в Store. Что касается найма, долгое время, первые годы-три у нас в команде сначала был один разработчик Smart TV, который, помимо этого, делал еще Android TV и Apple TV. Потом нас стал 0.5 разработчика.

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

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

Hexlet (20:52.845)
поняли, что смарт-тв очень тяжело на рынке и в целом очень тяжело их найти, то в какой-то момент пошли именно в эту сторону. То есть искали смарт-тв, ой, фронтенд-разработчиков и на этапе собеседования говорили им, что, ребят, вот есть такая тема, го. Ну да, знакомая история, в общем, мы проходили тот же самый этап, момент. Но интересно, что у вас, я правильно понимаю, что что с Android TV, Apple TV у вас все-таки...

Отдельно от Smart Off. Сейчас отдельно, да, уже давно отдельно. Это прям в самом-самом начале было. Там есть такая штука, называется Cordova. На базе Cordova, насколько я помню, это все дело крутилось. Если я правильно понимаю, это штука, чтобы упаковывать... Да, да, она по сути упаковывается. Приложение в нативный формат для девайсов. Да, да, все так. А сейчас вас это прям отдельно, отдельно или все-таки у вас Android TV и Android приложение это что-то общее?

Android TV и Android приложение общие. У них даже общий package name, но внутри, понятное дело, разделяется в зависимости от устройства. И в целом для Android это нормально. То есть это его нативное поведение. Да, просто разный интерфейс в зависимости от того, ты запускаешь на телек его либо на Android мобильном. Из интересного иногда видим, что какие-то китайские устройства мобильные прикидывают с TV, либо TV прикидывается мобильным.

И приходит какое-то огромное количество крышей просто потому что интерфейс перерисовывается. И второй тоже забавный случай буквально пару дней назад был. На проверке в Story тоже запустили не на том типе устройств. Я прислал Reject с Android TV с интерфейсом Mobile. Что касается Apple тоже команда iOS занимается.

То есть они отдельно, ну там отдельно, они отдельно делают iOS приложение, отдельно TOS приложение. То есть все-таки не объединили тоже? Нет, оно не объединили, но оно отдельно нас развивается. Понял. А Samsung и LG получается на базе этого самого фрейворка, единое приложение? Да, но при сборке, соответственно, мы собираем там, так как это тоже довольно, скажем так, разные типы устройств, у них своя операционная система.

Hexlet (23:19.053)
которые очень сильно и различаются и имеют какие-то свои там... у них гайды очень сильно разные, то да, под них мы просто собираем перед отправкой Store отдельные пакеты в зависимости от того, куда это уходит. Ну, это достаточно изящно вообще. Я, честно говоря, до сих пор удивлён, что вообще есть фреймбурки, которые позволяют хоть что-то там поделить, потому что реально это два разных устройства без как бы... Причём...

У LG еще не самая лучшая поддержка, и всегда вообще можно стучаться и понять, что происходит. Окей, с клиентами разобрались. Давай поговорим о том, устроена серверная инфраструктура всего этого дела. Предположу, что вас на российском микросервисе, как у всех сейчас, модно-молодежно. Почти везде. А как можно почти везде? Ну, мы дораспиливаем Monolith, который был изначально на запуске платформы, на запуске сервиса.

когда мы запускались был Монолит. Вы его тоже, прости, сами тоже его собрали? Тут довольно интересная история. Был и, наверное, есть проект такой Молодежь ТВ. Если, может, знаешь, сериал такой старый, даешь молодежь. Вот. Вот есть проект такой Молодежь ТВ. Создатель этого проекта, до сих пор работает в нашей компании и сейчас руководит рентгия отделом.

Он для этого проекта написал платформу, админку, сайт и какие-то еще базовые элементы, которая позволяла выкладывать серии этого сериала на сайте Молодежь ТВ. Этот проект был взят за основу в целом старта и на его основе старт создавался. Части этого проекта до сих пор работают.

и составляет довольно, ну скажем так, важную часть нашего сервиса. Вот. Но мы планируем в этом году полностью это все дело переписать и уже уйти в сторону полностью микросервисной архитектуры. А сколько лет назад это было? Это было 6 лет назад. Ну, старт запустился 5,5 лет назад, в октябре 2017 года.

Hexlet (25:34.637)
развитие началось за год до этого, ну где-то да, около там 6-6 с половиной лет назад. Вот этот предшественник, он же Владюш ТВ, это что же, не один человек делал? Нет, это делал один человек. Один человек. То есть не могу не отметить, один человек сделал что-то, что 6 лет работает в продакшене до сих пор, и это не перепилило до сих пор целая команда. Это довольно-таки замечательный Ну давай про то, у вас с микросервисами, я так понимаю, что вас там ГОИ и Питон, да, в основном.

Как вообще вы это все проектируете? У есть какой-то архитектурный отдел? Откуда вообще все исходит? Смотри, архитектурного отдела нет. У нас в целом вся техническая команда это на текущий день 99 человек. Это вообще это все. Это инфраструктура, тестирование, разработка, ПМы, там ИА. Вот. Ну, без DWH, наверное? Да, DWH тоже у нас, да. И вместе с DWH, с R &D.

99 человек. И вот этот рост, да, вот к этому числу мы пришли на самом деле не так давно, год назад, или там полтора года назад, в команде было человек 35-40 всего, то есть у нас довольно бурный рост за последнее время произошел. И ну скажем так, вот такой небольшой команды сложно было, это все дело там как-то...

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

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

Hexlet (27:58.445)
И в части проектирования каких-то сложных вещей мы собираем встречи, накидываем какие-то идеи относительно того, как это можно реализовать. Сейчас стараемся уходить в историю, когда кто-то берет на себя ответственность по подготовке различных вариантов, как им можно эту реализацию осуществить. И после мы собираемся, обсуждаем и выбираем то, что...

Там нам больше всего подходят с учетом, возможно, будущих каких-то вещей, которые мы видим, которые стоит менять и так далее. Как часто появляется новый микросервис? Наверное, не знаю, может, в квартал может появиться. Довольно часто, наверное. Звучит все-таки то, что вас там не так, что прям целый зоопарк. Сколько на скидку примерно? Штука 30, наверное.

20-30 штук. Это такие основные. Ну есть прям микро- микросервис, которые какую-то там простую функцию делают. Вот. Но вот из основных, которые там связаны и влияют на пользовательный бизнес, наверное, да, около 20-30. Интересно, как у вас построено взаимодействие между клиентами и бэкэндом, ну в плане между разработкой клиентов и бэкэндной части? Вы вас катируете в спецификации, тз, вот это все? Конечно. Ну, смотри, у нас...

Как таковых системных аналитиков нет в команде, как так исторически сложилось, и я собственно в команду приходил как там project manager IT, не было системных аналитиков, и вот эта функция, она у нас внутри project. Соответственно, project у нас такие очень скиловые ребята, которые берут функциональные требования, которые получают от команды продукта и превращают их в TZ. В TZ довольно...

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

Hexlet (30:21.837)
Ребята разделяются тоже там, они у функционально, кто-то занимается конкретно например бэк эндом, больше кто-то занимается больше фронт энд частями и они просто эту задачу разбивают внутри себя, внутри команды, кто за какую часть отвечает. При этом, наверное ты сам знаешь, ну или там часть вещей, которые могут влиять на реализацию, они зависят например от того, как макеты нарисуют. То есть мы там даже дожидаем сначала.

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

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

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

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

Hexlet (32:41.485)
которая занимается покрытием в целом, плюс занимается нагрузочным тестированием всем остальным, то есть она в целом отвечает за все автотестирование на проекте, плюс внутри ребята, которые занимаются там в частности тестированием бэкэнда, мы в какой-то момент там части них отправили на курсы и не сами хотели там развиваться, не просто руками тыкать в постмени. Вот. А...

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

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

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

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

Hexlet (35:00.077)
минимум проверить на корректность работы вашего приложения, вашего сайта. меня возникает самый для меня лично больной вопрос. Это, собственно, стриминг. Потому что на браузер стаки работает далеко не весь. У вас вообще есть? Прополагаю, что есть, DRM. Есть. То есть цифровая защита контента. Вот, физическая достаточно история. У вас есть какие-то тесты, связанные с его работой? Тестов, связанных с DRM, наверное, не

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

Fairplay, Play Ready и White Wine. Play Ready? А есть не секрет на каких устройствах у Play Ready? Play Ready на смартах я знаю работает. Вот. И старые, вот я не помню, Edge, Edge старые, они по-моему тоже на Play Ready работали. Но они могут. Да. Вот текущие они на базе Chromium сделали, и там Dash. Вот. А старые вроде в Play Ready, да.

Любопытно. Мы, мне кажется, выпили практически сразу, потому что обнаружили, что вообще все вещества, парку устройств, которые есть по крайней мере в нашей аудитории, работают на… Ну, на HLS, в общем, шифрованном практически без включений. Ну, прикольно. У вас есть люди, которые понимают, на низком уровне как это работает? Есть пару человек. Им приходится надо включаться в какие-то там исследования аномалий, скажем так. Или как вообще, скажем, новую устройство коопступает, ну…

Сейчас же выходят какие-то новые модели телевизоров, сборки сберов и так далее. Как вообще вы подходите к тому, чтобы понять, а что там, собственно, будет работать и насколько хорошо, и может быть, какие там есть нюансы? Подключается обычно тестирование. То есть они проверяют с своей стороны, что все корректно работает. В случае, если происходят какие-то проблемы, уже идем в разработку и продолжаем там разбираться. и новое устройство обычно нас не появляется просто так. То есть есть отдельная команда...

Hexlet (37:23.341)
внутри сервиса, который занимается в целом партнерскими интеграциями, это ребята, которые тех самых вендоров к нам и приводят. И обычно вот именно так это происходит. То есть у нас в случае необходимости есть контакт, и мы можем там обратиться и уточнить какие-то вопросы. Но, насколько я помню, за последнее время что-то такого серьезного не было. То есть все...

те вендора, которые приходят, Android-based устройства и там все в целом адекватно и понятно. Да, надо признать, что последние годы все-таки рынок всех этих платформ как-то гомогенизируется, да, в основном. Ну даже браузер, что пошло практически в все надежды Chromium'а, как бы очень немного выживших пользуются Opera и Firefox. Все остальное, кроме Safari, это Chromium. Это, безусловно, облегчает нашу жизнь. Окей.

Как вы вообще работаете с качеством смотрения? Я просто знаю по себе, что это очень больная тема, как раз потому что на каждом устройстве есть еще масса локальных нюансов. У кого-то там расширение для браузера, у кого-то там VPN, кого-то там Firewall, кого-то роутер. В общем, есть куча разных нюансов. И то, что работает тестирование, может там на аудитории выдают совершенно уникальные артефакты. Вы наверняка уже выстроили систему телеметрии, чтобы все это собирать. Может быть, расскажешь немножечко об этом.

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

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

Hexlet (39:44.909)
было сделано. есть первое это свой CDN. Там мы стараемся, ну сейчас мы довольно много у нас есть стыков, есть стыки со всеми основными AX. Потихоньку там подключаем пиринги напрямую с операторами, для того чтобы качество доставки было лучше. Пробовали подключать сторонние CDN, у которых есть более

широкая сеть доставки контента и как раз таки по телеметрии сравнивали есть ли разница в доставке между доставкой от нашего CDN и доставкой от стороннего сервиса и какой-то разницы не увидели. Второй момент это работа с кодированием. Кодируем мы тоже сами, мы не используем какие-то внешние кодировщики. Изначально использовали, как только запустились, но наверное в 2019 году написали свой.

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

трафик почти на 30 процентов. Вот, выкатив новый профиль. И продолжаем дальше работа в этом направлении. 30 процентов это прям космос, мне кажется. Это да, я сам офигел. Это был эффект, который ушел в ожидание, я полагаю, да? Ну, давай так, будем честны, что профиль мы не трогали довольно давно, наверное пару лет точно, и как-то там с этим жили, вот. И такие...

решили, что нет, надо что-то с этим делать, потому что все-таки довольно там больно было в некоторых случаях. У нас был завышенный очень сильно профиль, то есть если мы когда запускались, позиционировали себя, смотреть как у нас круто, наше Full HD лучше чем 4k конкурентов. Это действительно было так, то есть мы специально там завышали битрейт, вот, а сейчас мы пошли в сторону уменьшения, чтобы...

Hexlet (42:09.453)
качество было получше с точки зрения доставки. вообще вы готовитесь? Понятно, что когда выходит новый контент, ожидается высокая повышенная нагрузка. Как вообще вы готовитесь к таким штукам? На что вообще вы смотрите? Можно сказать что-то про ваш мониторинг? На сколько плотно вы обложены кибанами, графанами и всем остальным? Все эти инструменты у нас конечно же есть. Что касается вообще, кстати, инструментов мониторинга и алертинга.

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

и сейчас подключаем внутри себя OpenTelemetry тоже для самостоятельного сбора логов и анализа. Вот потихонечку сейчас прикручиваем именно мониторинг. Вот, ну а Lerting сделан в телегу там бот и есть, который в случае чего alertит нам в почту там еще куда-нибудь. По поводу мер, ну у нас есть прогнозы, то есть мы перед запуском у нас есть определенный тайнлайн по запуску наших проектов.

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

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

Hexlet (44:30.669)
примерно можем представить себе, что у нас там произойдет, то есть к чему нам готовиться. Плюс я со своей стороны, конечно же, перезакладываюсь. Это касается в целом RPS, в котором может наша API выдержать, наши сервисы, которые могут выдержать. То есть мы примерно понимаем, что если пользователи придут и будут осуществлять отдельные действия, то основная нагрузка сляжет на отдельные сервисы. То есть мы, если видим, что

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

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

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

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

Hexlet (46:49.901)
смотреть телевизор, самый высокий нагрузка. есть профиль примерно такой. И мы, конечно же, в первую очередь обращаем внимание на пик. То есть нас интересует пик, нас интересует то время праймтаймовое, чтобы мы вот в пике могли всем, тем пользователям, которые к нам приходят, отдать все, что они хотят. Да, и история такая, что вырос в два раза на первой серии.

на премьере, на премьере второй серии вырос еще в два раза и на следующий день, по-моему, один из провайдеров, который предоставлял нам канал, он нам прислал уведомление о том, что произошла авария на Узле и в день премьеры, то ли третьей, то ли четвертой серии, будет на полдня с 12 утра до ночи

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

знают насколько это тяжело и как нам сложно это далось. В общем нашли контакты, все это сделали. Плюс с учетом вот такого активного роста нужно было срочно запускать еще один узел седен в эксплуатацию, потому что текущие не справлялись. И нам удалось. Мы запустили его в 7 вечера, день дня премьеры. Пик у нас где-то в районе 22-30-23.

Вот. И вот уже когда, скажем так, подходило к краю, мы запустили еще один узел и успешно с этим справились. В общем, испытали его, сразу боем, так сказать. Да. Было страшно, честно скажу. Было страшно. Хотелось бы таких историй, чтобы больше не повторялось. Тут могу только согласиться. Конечно, все эти истории всегда пьют максимум крови всего физического персонала. Ну и как бы, особенно, я думаю, тут...

Hexlet (49:09.037)
Примерно все сервисы производят контент в одной нише, что ведь надо понимать, что за всеми этими премьерами следят люди, которые все их снимают. А это, как правило, достаточно серьезные ребята, которые не очень любят, когда контент недоступен в момент премьеры. Такой еще вопрос, я думаю, что он максимально рактуален в последние периоды. Наверняка вы сталкиваетесь с угрозами, скажем так, безопасности, дедоса или, наверное, какие-нибудь хакеры неэтичные и все прочее. Как вообще у вас...

Может быть, есть чем поделиться по этому направлению? Как вы работаете с такими угрозами? Да, иногда приходят всякие нехорошие ребята. Мы сейчас не используем каких-то внешних решений. Мы пробовали работать с куратором, пробовали ещё с кем-то работать. Они довольно дорогие, и, наверное, для нас там не представляет какой-то… Нет необходимости использования каких-то внешних решений.

У нас есть при этом отдельный API мы через DDoS канал одного из провайдеров заворачиваем. Там его настроили. Вообще любая настройка DDoS это такая очень сложная и тонкая операция. Потому что нужно хороших пользователей не отрубить. Это очень сильно сказывается на бизнесе.

И активно используем rate-лимиты, есть своя банн-база, можно так сказать. И в целом следим за всплесками, то есть если кто-то приходит, то активно за этим следим. Ну и, наверное, главное, мы стараемся в целом проектировать свой сервис таким образом, любой DDoS был нам не помехой и не влиял на работу сервиса. То стараемся из этого исходить.

А можешь, пожалуйста, уточнить? То есть это речь про отказ устойчивости отдельных сегментов как бы сей эксистемы или... В том числе. Ну, то есть вообще, как говорят, да, не бывает плохого дедоса, бывает мало денег. Ну, в общем-то, да. Да, вот. Поэтому, ну, скажем так.

Hexlet (51:22.573)
Те сервисы, которые необходимы пользователю для того, чтобы нашим сервисам пользоваться, те сервисы внутренние, они максимально защищены. То есть мы многое что там кэшируем, плюс у нас есть определенный регламент, что в случае, если там что-то идет не так, и количество запросов, которые к нам прилетают, наши сервисы могут не обслужить, то есть регламент по…

отключению сервисов и функциональности, которая не критична и не влияет на работу сервиса в целом. есть вот мы такой подход выбрали. Это вручную делается или это какой-то автоматизировано? Нет, это делается вручную. Да, автоматизировано довольно сложно это, скажем так, сделать по причине ложных срабатываний в первую очередь. То сложно сказать, что...

обучить. Не тот случай, когда лучше перебдеть, чем не добдеть. Все верно. Немножко еще про команду хочу поспрашивать. Ты уже упомянул количество. Можешь примерно в процентах, кто чем занимается? Сколько людей на клиента, сколько на бэкэнда, сколько остальных? Как много девописов особенно интересно, аучить зашиваться все свое на железе? Так, а я сейчас могу сказать. Это сказать очень просто.

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

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

Hexlet (53:41.965)
Это руководитель отдела эксплуатации и еще там 4 человека. Это админы, девопсеры. есть все эти люди, которые занимаются у нас сырой инфраструктурой. Из них вот двое вышло не так давно. То есть вот, можно сказать, до конца прошлого года у нас было всего 7 человек в эксплуатации. Вот это, считаю, не так много. Ну теперь получается по шишке 10 % команды. Ну сейчас 9, да. Сейчас 9 человек. Группа R &D у нас это 2 человека.

ребята занимают всякими интересными вещами, ищут какие-то, пробуют новые истории, которые появляются активно в современном мире. Проектный офис у нас это тоже девять человек, это те самые project-менеджеры, которых я говорил раньше. Что касается департамента разработки, в самом департаменте получает 78 человек, это руководитель разработки, отдел тестирования 37 человек всего.

Ну это треть компании, мое уважение. Они у нас разбиты по направлениям, то есть у нас есть внутри отдельные команды, отдельная команда мобильного тестирования, Smart TV тестирование, тестирование бэкенд, тестирование фронта. Плюс авто-тестирование. То есть пять получается команд и Head of Co-op. Бэкендеров у нас 12 человек, суммарно. Смартов пять.

3 человека на DWH, 10 человек на web и по 5 человек на iOS и Android. В общем, да, знакомые, здоровые пропорции, я бы сказал. Ну, а дело тестирования, конечно, мощный, в принципе. Можно понять, почему так много решается, в том числе, ресурсом. Если не сильно благо копать, у вас есть какая-то система внутреннего градирования или повышения...

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

Hexlet (56:05.837)
и не просто градирование, а компетенции, необходимых для нахождения на том или ином уровне. Вот этот процесс идет прямо сейчас. Мы его запустили в начале этого полугодия. Мы долго к нему готовились. Сейчас, наверное, к концу этого полугодия мы планируем провести первый этап оценки, можно так сказать. Но мы это рассматриваем в первую очередь как

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

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

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

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

Hexlet (58:25.069)
Вы стараетесь отбирать людей посильнее или у вас есть все ступени развития? Зависит от необходимости. Когда планируем бюджет фото, бюджет по найму на год, мы смотрим в том числе на те задачи, которые нам предстоит решать. Смотрим на ту команду, которая у нас есть сейчас. Стараемся прогнозировать то, как люди могут вырасти.

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

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

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

Ну, рад, что ты это упомянул. Задам еще такой бонусный вопрос. Ты перед интервью упомянул, что ты пришел в компанию, если правильно понял, в качестве проект-менеджера. Да. Того самого технического проект-менеджера, который как бы понимает, что к чему, что откуда берется, практически одной ногой бизнес-аналитик. Для тех людей, кто нас слушает, может быть, поделишь немножко своим карьерным путем и как вот это все тебя привело к тому, что ты теперь руководитель всей технической репортаментной компании? Я свой опыт начал с Эникея, потом

Hexlet (01:00:45.229)
системное администрирование, работал в компании, обслуживал офисы с точки зрения системного администрирования, там доработал до должности технического директора, но CIO. это да, IT-директор, можно так сказать, IT-директор это был крупный туристический холдинг, когда туризм еще активно жил и очень сильно развивался. Много разных интересных вещей там делали.

Плюс я там получил очень много опыта в смежных областях. Там SEO, маркетинг, у нас была своя видео студия, то есть мы там снимали аналоги там подкастов, какие-то такие вещи делали. Это дало мне, скажем так, общения с людьми из разных областей. Плюс у нас там была своя активная разработка, у нас был свой подбор тура, который мы активно развивали. И...

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

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

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

Hexlet (01:03:07.629)
Вот, но да, меня опыта промышленной разработки нет, но при этом есть очень хорошее понимание того, как это все дело работает и в целом, конечно же, знание всех тех... ну не всех, а около технологий, оно необходимо, конечно же. А где ты вообще это набрался? То есть как ты узнал там, что бывает кафка, что там бывают всякие базы данных, что там есть там Kotlin, Swift, Flask и все остальное? Наверное, любопытство можно.

так сказать. Есть? Нет, есть на самом деле.

книги, да, много разных книг. там когда… Я просто ж не просто там программировать сел когда-то, да. Я взял книгу, начал читать, и в любом случае там в книгах так или иначе теленые технологии, указываются, и ты просто копаешь, копаешь, копаешь, натыкаешь на какое-то незнакомое слово, а что это такое и так далее. Так вот оно, собственно, и появляется. Вот. Сейчас, я думаю, с этим стало намного проще.

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

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

Hexlet (01:05:12.109)
Ну, мне кажется, это самая важная вещь для любопытства. Для любого инженера, мне кажется, один из самых главных притерий успехов, в чем бы то ни было, потому что большая часть знаний не идет сама в твои руки, ее нужно откуда-то добывать сильно и превозмогать зачастую. Да, все верно. Кирилл, спасибо большое за это интервью, было очень поздно. Спасибо тебе.

Уверен, что многим нашим зрителям не все было понятно, о чем мы тут говорили, но тем больше мотивации учиться развиваться и изучать. Спасибо, что были с нами. Ставьте лайк этому видео, подписывайтесь на канал, нажимайте колокольчик, это все помогает нам снимать новые видео. Оставляйте комментарии. Пока, спасибо.