Самый забавный собес в моей карьере
Собеседовался я как-то в компанию, которая занималась форексом, да, эдакое легальное казино. Было четыре основных этапа: HR, техсобес, разговор с CEO и секретный этап, о котором позже.
Первая вещь, которая меня смутила, — все этапы нужно было обязательно записывать на камеру. В тот момент для меня это было просто странно, а позже стало практически красным флагом.
Первые три этапа прошли нормально, даже сказать особо нечего: дефолтные вопросы от HR, очень базовые вопросы по Android и что-то вроде «behavior-интервью» с CEO. Но вот последний этап... уф. Готов поспорить, я вас удивлю.
В 99,9% случаев финальный этап — это командный фит. Созваниваетесь с будущими коллегами, обсуждаете, кто какие сериалы любит, и довольные расходитесь. HR про этот этап говорила очень расплывчато, но я был уверен, что будет именно фит.
Подключаюсь я к созвону — и вижу только одну женщину в возрасте, которую раньше не встречал. Она, обращаясь ко мне на «вы», говорит:
— Добрый день. У нас финальный этап — разговор с психологом. Мы составим ваш психотип чтобы понять, подходите ли вы команде.
И тут, как у Лавкрафта, мой ахуй был неописуем. Уже в этот момент я понял: хоть в оффере и мелькали цифры выше рынка, но этого явно недостаточно. Из чистого любопытства решил пройти этап до конца — интересно же, куда это приведёт.
По факту — ни о чём. Она задавала какие-то рандомные вопросы. Из забавного — попросила описать алгоритм приготовления яиц. Возможно, позиция предполагала готовку завтраков, кто знает. Потом она обратила внимание на мою футболку — с Шляпником и Котом из «Алисы».
Начала рассуждать, что мой выбор футболки многое говорит: «Алиса» — жанр абсурда, это указывает на высокий интеллект... Кто читает меня давно, понимают насколько она промахнулась. Футболку, если честно, надел просто потому, что не было других чистых вещей — ведь я, как и положено тру-айтишнику, стираюсь раз в год.
Короче, закончив этот карнавал кринжа, я написал HR, что ничего не выйдет — я полюбила другого. Как я слышал у этой компании в итоге дела были не очень, и очень многих сократили. На данный момент — пожалуй, моя самая забавная история с собесов.
А у вас были похожие?
Собеседовался я как-то в компанию, которая занималась форексом, да, эдакое легальное казино. Было четыре основных этапа: HR, техсобес, разговор с CEO и секретный этап, о котором позже.
Первая вещь, которая меня смутила, — все этапы нужно было обязательно записывать на камеру. В тот момент для меня это было просто странно, а позже стало практически красным флагом.
Первые три этапа прошли нормально, даже сказать особо нечего: дефолтные вопросы от HR, очень базовые вопросы по Android и что-то вроде «behavior-интервью» с CEO. Но вот последний этап... уф. Готов поспорить, я вас удивлю.
В 99,9% случаев финальный этап — это командный фит. Созваниваетесь с будущими коллегами, обсуждаете, кто какие сериалы любит, и довольные расходитесь. HR про этот этап говорила очень расплывчато, но я был уверен, что будет именно фит.
Подключаюсь я к созвону — и вижу только одну женщину в возрасте, которую раньше не встречал. Она, обращаясь ко мне на «вы», говорит:
— Добрый день. У нас финальный этап — разговор с психологом. Мы составим ваш психотип чтобы понять, подходите ли вы команде.
И тут, как у Лавкрафта, мой ахуй был неописуем. Уже в этот момент я понял: хоть в оффере и мелькали цифры выше рынка, но этого явно недостаточно. Из чистого любопытства решил пройти этап до конца — интересно же, куда это приведёт.
По факту — ни о чём. Она задавала какие-то рандомные вопросы. Из забавного — попросила описать алгоритм приготовления яиц. Возможно, позиция предполагала готовку завтраков, кто знает. Потом она обратила внимание на мою футболку — с Шляпником и Котом из «Алисы».
Начала рассуждать, что мой выбор футболки многое говорит: «Алиса» — жанр абсурда, это указывает на высокий интеллект... Кто читает меня давно, понимают насколько она промахнулась. Футболку, если честно, надел просто потому, что не было других чистых вещей — ведь я, как и положено тру-айтишнику, стираюсь раз в год.
Короче, закончив этот карнавал кринжа, я написал HR, что ничего не выйдет — я полюбила другого. Как я слышал у этой компании в итоге дела были не очень, и очень многих сократили. На данный момент — пожалуй, моя самая забавная история с собесов.
А у вас были похожие?
За всё время существования HTTP есть один спор, который, к моему удивлению, не прекращается до сих пор. В протоколе есть коды ошибок, которые возвращает сервер:
👉 200-е — всё ок,
👉 300-е — редиректы,
👉 400-е — косяк клиента,
👉 500-е — косяк сервера.
Спор всегда идёт о 400-х ошибках. Вот, например, у нас есть ресурс
На моей первой работе архитектор говорил, что 404 нужно возвращать только если мы обратились к endpoint-у, которого не существует, например, к
Меня вот что поражает. Группа очень умных людей разработала протокол, в котором учли всё, что можно. Чётко описали, какой код когда использовать. Написано широкую на широкую, ебанные волки, но нет — давайте спорить о фигне, которую уже давно решили.
Потому что если подумать, то обращение по несуществующему id и к неправильному endpoint-у — это одно и то же. В обоих случаях вы обращаетесь по неверному идентификатору, и в обоих случаях нужно возвращать 404.
Другой, самый ублюдский подход — это всегда возвращать 200, а ошибку описывать в теле ответа. Таких ребят я не в коем случае не виню, все таки писать код с лишними хромасомами тяжело. Наверное, есть мнение, что при ошибке нельзя вернуть тело, в котором можно описать, что за ошибка, поэтому будем использовать 200 хз.
Короче, не усложняйте там, где не нужно. Все библиотеки для работы с HTTP по умолчанию умеют обрабатывать коды ошибок — если они указаны как ожидается, а не когда мы возвращаем 500 если немного ошиблись в полях при запросе.
👉 200-е — всё ок,
👉 300-е — редиректы,
👉 400-е — косяк клиента,
👉 500-е — косяк сервера.
Спор всегда идёт о 400-х ошибках. Вот, например, у нас есть ресурс
users/{id}. Если мы попытаемся обратиться по id, которого нет, что должен вернуть сервер: 404 или 400 со специальным описанием, что ресурс не найден?На моей первой работе архитектор говорил, что 404 нужно возвращать только если мы обратились к endpoint-у, которого не существует, например, к
persons/{id}, а не к users/{id}. Я с ним что тогда был не согласен, то и сейчас.Меня вот что поражает. Группа очень умных людей разработала протокол, в котором учли всё, что можно. Чётко описали, какой код когда использовать. Написано широкую на широкую, ебанные волки, но нет — давайте спорить о фигне, которую уже давно решили.
Потому что если подумать, то обращение по несуществующему id и к неправильному endpoint-у — это одно и то же. В обоих случаях вы обращаетесь по неверному идентификатору, и в обоих случаях нужно возвращать 404.
Другой, самый ублюдский подход — это всегда возвращать 200, а ошибку описывать в теле ответа. Таких ребят я не в коем случае не виню, все таки писать код с лишними хромасомами тяжело. Наверное, есть мнение, что при ошибке нельзя вернуть тело, в котором можно описать, что за ошибка, поэтому будем использовать 200 хз.
Короче, не усложняйте там, где не нужно. Все библиотеки для работы с HTTP по умолчанию умеют обрабатывать коды ошибок — если они указаны как ожидается, а не когда мы возвращаем 500 если немного ошиблись в полях при запросе.
Forwarded from Банки, деньги, два офшора
В Москве изобрели программу, которая собирает досье на всех сотрудников и прогнозирует увольнения. Компания Infowatch уже запатентовала свою разработку. Проект анализирует действия каждого специалиста, затем фиксирует его стандартное поведение и любые аномалии. Программа учитывает, какие сайты посещает работник, что пишет на корпоративной почте, как часто опаздывает и даже матерится ли он в чате. В итоге детектор увольнений может сказать заранее, когда человек потерял эффективность, стал нелояльным или готовится уйти. Софт уже начали продавать компаниям. @bankrollo
Forwarded from Denis Sexy IT 🤖
Я обещал написать, как я готовился к интервью в JetBrains обвешавшись нейронками – я не забыл, делюсь
Прохождение интервью, немного другой скилл, нежели реальная работа – это про структурную презентацию прошлых достижений, в максимально сжатой форме и чем больше у вас достижений, тем больше нужно сжимать резюме и знать как презентовать
Я уже писал, что мне было интересно найти работу не как мини-инфлюенсеру через этот канал, а пройти собеседование на основе моего резюме – метил я в позиции где доступно принятие решений в продукте и робот Computer Use, как раз пошуршав на линкедине принес ссылку, что JetBrains ищет Group Product Manager в Амстердаме
Я решил попробовать откликнуться, и после того как назначили дату интервью, начал готовиться – попробую описать коротко шаги, вдруг кому-то поможет:
💬 1. Я поискал русскоязычные ТГ-каналы, которые ведут люди причастные к продакт менеджементу и наткнулся на канал @productdo; его ведут ребята из Booking, и много там рассказывали как проходит найм в Booking
💬 2. Искать посты или читать ВЕСЬ канал в 2025 уже не принято; поэтому я скачал весь их канал (сорри, чуваки!) через ТГ приложение Windows в формате JSON (Нужно нажать на ⋮ в канале и выбрать скачать JSON)
💬 3. После этого, я пошел на AI Studio от Google и прописал там:
системный промпт эксперта-суммаризатора знаний для собеседований (сделал его тут, иконка с бейджиком), в
Какая идеальная структура собеседования, для прохождение интервью в Booking, используй текст ниже:
<я тупо вставил JSON текст который скачал в пункте 3, никак его не обрабатывая>
💬 4. Выбрал модель Gemini Flash (берите последнюю доступную) и выставил температуру 0, чтобы модель не креативила ничего и запустил. Кстати, с тех пор вышла бесплатная Gemini Pro 2.5, можете ее брать.
💬 5. Модель шуршала своим гигантским контекстом в миллион токенов минуты две и после этого выдала структурный текст идеального флоу прохождения интервью – как правильно презентовать свои достижения, как правильно выбрать важные части и не важные и тп
💬 6. Естественно, первому ответу модели верить не стоит, поэтому в этом шаге тупо пишем ей:
Убедись, что ты не допустила ошибок, перепиши ответ если ошибки есть
💬 7. И все, получаем новую версию вопросов для интервью, которая почти не содержит галлюцинаций – в тексте было описана как условный Booking тестирует людей при найме, какие вопросы задает и тп.
💬 8. Дальше, создаем новый чат и выбираем в той же Google AI Studio модель Gemini Pro, в системный промпт прописываем «Эксперта по прохождению интервью» (опять же, тут генерируем системный промпт для этой роли)
💬 9. Дальше, вставляем в
Покажи как идеальный кандидат на позицию X, прошел бы интервью и ответил на эти вопросы:
<тут вставляем вопросы для интервью>
При учете что резюме кандидата выглядит так:
<тут вставляем свое резюме в виде текста>
💬 10. Выставляем температуру на 0.3, запускаем модель
💬 11. В итоге получаем ПРИМЕРНОЙ сценарий того, как могло бы выглядеть интервью, какие вопросы могли бы задавать, как ответы могли бы звучать – все это не совсем релевантно, но позволяет очень быстро начать готовиться к конретике правильно адаптируя свой спич под привычный для найма флоу
💬 12. Дальше, вы можете показать этот текст приложению ChatGPT (тупо включив режим с видео, наведя на монитор камеру и скролля текст) и попросить вас пособеседовать, позадавать вопросы, оценить ответы
⚠️ Важно:
Этот способ не гарантирует успех прохождения интервью, но это самый лучший способ, что я пробовал – потому что после него я был уверен в себе, вопросах и тому как правильно презентовать весь этот зоопарк проектов к которым я был причастен
Успехов и меньше нервов – все проблемы всегда возникают от волнения, потому что у вас скорее всего тоже синдром самозванца, а этот метод позволяет его победить
Прохождение интервью, немного другой скилл, нежели реальная работа – это про структурную презентацию прошлых достижений, в максимально сжатой форме и чем больше у вас достижений, тем больше нужно сжимать резюме и знать как презентовать
Я уже писал, что мне было интересно найти работу не как мини-инфлюенсеру через этот канал, а пройти собеседование на основе моего резюме – метил я в позиции где доступно принятие решений в продукте и робот Computer Use, как раз пошуршав на линкедине принес ссылку, что JetBrains ищет Group Product Manager в Амстердаме
Я решил попробовать откликнуться, и после того как назначили дату интервью, начал готовиться – попробую описать коротко шаги, вдруг кому-то поможет:
системный промпт эксперта-суммаризатора знаний для собеседований (сделал его тут, иконка с бейджиком), в
User Message вставил текст в стиле:Какая идеальная структура собеседования, для прохождение интервью в Booking, используй текст ниже:
<я тупо вставил JSON текст который скачал в пункте 3, никак его не обрабатывая>
Убедись, что ты не допустила ошибок, перепиши ответ если ошибки есть
User Message: Покажи как идеальный кандидат на позицию X, прошел бы интервью и ответил на эти вопросы:
<тут вставляем вопросы для интервью>
При учете что резюме кандидата выглядит так:
<тут вставляем свое резюме в виде текста>
Этот способ не гарантирует успех прохождения интервью, но это самый лучший способ, что я пробовал – потому что после него я был уверен в себе, вопросах и тому как правильно презентовать весь этот зоопарк проектов к которым я был причастен
Успехов и меньше нервов – все проблемы всегда возникают от волнения, потому что у вас скорее всего тоже синдром самозванца, а этот метод позволяет его победить
Please open Telegram to view this post
VIEW IN TELEGRAM
Интересные вайбы возникают, когда уходишь в отпуск в 2025. На секунду отвернулся, а там уже вышло 48 новых агентов, которые угрожают тебя заменить.
Зинатутин у себя в твиттере написал про свой SaaS, который они пилят с другом. Кто не знает, Зинатулин это топовый инфраструктурщик в мире Android.
Это очень показательный пример того, как крутой инженер пытается запустить свой продукт. Он очень много описывал про то, как у них все круто покрыто тестами, что они все сразу оптимизируют под ARM, чтобы все летало, про то, что у них уже 8 (восемь КАРЛ!) микросервисов.
Когда же спросили, а что делает то продукт, какую проблему он решает? В ответ было, ну мы там запустимся соберем фидбек, короче позже отвечу.
Я бесконечно уважаю Зинатулина, но пока это выглядит очень потешно)
Это очень показательный пример того, как крутой инженер пытается запустить свой продукт. Он очень много описывал про то, как у них все круто покрыто тестами, что они все сразу оптимизируют под ARM, чтобы все летало, про то, что у них уже 8 (восемь КАРЛ!) микросервисов.
Когда же спросили, а что делает то продукт, какую проблему он решает? В ответ было, ну мы там запустимся соберем фидбек, короче позже отвечу.
Я бесконечно уважаю Зинатулина, но пока это выглядит очень потешно)
Когда смотришь, как сделаны логи в других системах, понимаешь, насколько круто реализованы логи в Java. Вот смотрите, основная проблема: у тебя есть какая-то библиотека, в которой есть логи. Есть два варианта, как их делать: забить и просто всегда выводить в консоль, либо ты каким-то образом предоставляешь клиенту возможность использовать свой логер.
В мире бэкенд-разработки на Java, разработчики сели, подумали и решили: а давайте сделаем общий интерфейс логов, на который все будут завязаны, и чтобы была возможность в runtime подставить реализацию, удобную клиенту. Так появился SLF4J. Поэтому все библиотеки для Java завязываются на SLF4J, и если у вас в проекте уже настроен логгер, он автоматически будет работать с этой библиотекой – весьма удобно.
В мире Android все либо используют Timber (или какой-то мультиплатформенный аналог), либо делают что-то свое. Библиотеки в основном предоставляют какой-то интерфейс для логов, например, Interceptor в OkHttp. Общего решения может и нет, но жить можно.
Однако в мире js все гораздо забавнее. Я делал сервис с использованием Next.js. Эти ребята вообще не заморачиваются с логированием, они просто выводят все в консоль. Нет никаких стандартных инструментов, чтобы это исправить. Что если мне нужно не в консоль, а в файл? Что если мне нужен особый формат? Вообще похую.
Решается это интересным способом. Так как JavaScript весь из себя такой гибкий, можно просто переопределить стандартную функцию вызова консоли на свою функцию, в которой мы уже вызываем нормальный логгер.
Ох уж эти фронтендеры, казалось бы, простая вещь, которая уже решена, но даже тут возникают сложности.
В мире бэкенд-разработки на Java, разработчики сели, подумали и решили: а давайте сделаем общий интерфейс логов, на который все будут завязаны, и чтобы была возможность в runtime подставить реализацию, удобную клиенту. Так появился SLF4J. Поэтому все библиотеки для Java завязываются на SLF4J, и если у вас в проекте уже настроен логгер, он автоматически будет работать с этой библиотекой – весьма удобно.
В мире Android все либо используют Timber (или какой-то мультиплатформенный аналог), либо делают что-то свое. Библиотеки в основном предоставляют какой-то интерфейс для логов, например, Interceptor в OkHttp. Общего решения может и нет, но жить можно.
Однако в мире js все гораздо забавнее. Я делал сервис с использованием Next.js. Эти ребята вообще не заморачиваются с логированием, они просто выводят все в консоль. Нет никаких стандартных инструментов, чтобы это исправить. Что если мне нужно не в консоль, а в файл? Что если мне нужен особый формат? Вообще похую.
Решается это интересным способом. Так как JavaScript весь из себя такой гибкий, можно просто переопределить стандартную функцию вызова консоли на свою функцию, в которой мы уже вызываем нормальный логгер.
Ох уж эти фронтендеры, казалось бы, простая вещь, которая уже решена, но даже тут возникают сложности.
Совет дня: на тренировках в зале лучше использовать большие наушники вместо AirPods. Я уже сбился со счета, сколько раз меня спасал ободок наушников от того, что я куда-то вьебался.
В программировании аналогом больших наушников является строгая типизация.
В программировании аналогом больших наушников является строгая типизация.
Сейчас с развитием LLM-агентов многие говорят, что программирование со временем очень сильно изменится. Оно будет больше похоже не на набор текста, а на что-то вроде игры в StarCraft, где у тебя куча юнитов (агентов) выполняют какие-то мелкие задачи, а ты выступаешь в роли стратега, занимаясь лишь разработкой архитектуры.
В целом это и сейчас можно сделать, только вот как это выглядит на практике: ты говоришь юниту идти добывать золото. Он идет добывать золото, затем почему-то переключается на добычу дерева. После вообще уходит на вражескую базу и добывает золото там. Затем идет к середине карты и пытается дать пизды NPC, а после возвращается на базу и начинает ходить по кругу.
В целом это и сейчас можно сделать, только вот как это выглядит на практике: ты говоришь юниту идти добывать золото. Он идет добывать золото, затем почему-то переключается на добычу дерева. После вообще уходит на вражескую базу и добывает золото там. Затем идет к середине карты и пытается дать пизды NPC, а после возвращается на базу и начинает ходить по кругу.
Мне нравился Arc как минимум за две функции:
👉 Можно было скопировать ссылку на страницу просто по Command + Shift + C. Возможно, в других браузерах есть то же самое, но я пока не нашел.
👉 Очень плавно работал Picture-in-Picture. Когда я в последний раз пробовал использовать эту функцию в Chrome, он не мог показывать PiP поверх других окон на Mac, а Arc — мог.
Из минусов, из-за того что панель управление находится сбоку, очень многие сайты сходили с ума, т.к не верстались под такое.
Когда Arc только появился, у них был встроенный AI-поисковик, но с появлением Perplexity необходимость в нём отпала.
Видимо, придётся возвращаться обратно в Safari. Чтош...
P.S. а ну и логин при старте конечно бесил жутко, тупее этого делать только логин в терминале
👉 Можно было скопировать ссылку на страницу просто по Command + Shift + C. Возможно, в других браузерах есть то же самое, но я пока не нашел.
👉 Очень плавно работал Picture-in-Picture. Когда я в последний раз пробовал использовать эту функцию в Chrome, он не мог показывать PiP поверх других окон на Mac, а Arc — мог.
Из минусов, из-за того что панель управление находится сбоку, очень многие сайты сходили с ума, т.к не верстались под такое.
Когда Arc только появился, у них был встроенный AI-поисковик, но с появлением Perplexity необходимость в нём отпала.
Видимо, придётся возвращаться обратно в Safari. Чтош...
P.S. а ну и логин при старте конечно бесил жутко, тупее этого делать только логин в терминале
Forwarded from addmeto (Grigory Bakunov)
В этот раз не шутят: закрывается браузер Arc. Да, тот самый "новый, перспективный, самый лучший", однако совершенно непонятно для кого сделанный браузер. Среди гиков пользователей было много, к сожалению, это самая неблагодарная аудитория.
Честно говоря, я с самого начала был против Arc ровно по этой причине — неясно, как выживет такой продукт и ради чего его поддерживать. У меня есть еще с десяток таких продуктов, под флагом "не инвестировать время в освоение интерфейса того, что умрет, т.к. выжить не сможет". Обычно из этого списка умирает 2-3 проекта в год.
Такие продукты не бесполезны, они двигают прогресс вперед. Я просто не советую людям инвестировать свои силы и время в то, что нужно только ради прогресса.
https://www.tgoop.com/blognot/6026
Честно говоря, я с самого начала был против Arc ровно по этой причине — неясно, как выживет такой продукт и ради чего его поддерживать. У меня есть еще с десяток таких продуктов, под флагом "не инвестировать время в освоение интерфейса того, что умрет, т.к. выжить не сможет". Обычно из этого списка умирает 2-3 проекта в год.
Такие продукты не бесполезны, они двигают прогресс вперед. Я просто не советую людям инвестировать свои силы и время в то, что нужно только ради прогресса.
https://www.tgoop.com/blognot/6026
Telegram
БлоGнот
The Browser Company объявила (опять) о закрытии разработки браузера Arc и переходе к новому проекту — AI-браузеру Dia. Основатель Джош Миллер признал три ключевые ошибки: слишком долго работали над Arc, несмотря на очевидные проблемы с ростом и удержанием…
По многочисленным заявкам (одной) я решил сделать серию постов про то, с чем в основном работаю последние несколько лет, а именно про CI/CD. Расскажу в целом про базу для тех, кто вообще это не трогал:
👉 Что такое пайплайн из чего состоит
👉 Как запускаются пайплайны и где выполняются
👉 Что такое self-hosted runner
👉 Как артефакты передаются между job
👉 Как работают UI тесты на CI
Для продвинутых:
👉 Варианты как ускорить пайплайны
👉 Подходы для отладки пайплайнов
👉 Какие задачи лучше не делать в CI
Поэтому не переключайтесь. Начало туть
👉 Что такое пайплайн из чего состоит
👉 Как запускаются пайплайны и где выполняются
👉 Что такое self-hosted runner
👉 Как артефакты передаются между job
👉 Как работают UI тесты на CI
Для продвинутых:
👉 Варианты как ускорить пайплайны
👉 Подходы для отладки пайплайнов
👉 Какие задачи лучше не делать в CI
Поэтому не переключайтесь. Начало туть
Forwarded from MyGap
Еще один дикий пример, как мы катимся к киберпанку и технологическому шоку.
Ютуб начал раскатывать автоматический дубляж в видео. Еще раз: АВТОМАТИЧЕСКИЙ ПЕРЕВОД твоей аудиодорожки.
То есть ты загружаешь свою обычную дорожку, где ты говоришь, например, на русском языке. Программулина ютуба каким-то магическим образом распознает звуки, которые ты говоришь.
Затем эти звуки она умеет имитировать, как умный попугай. А точнее - не просто имитировать, а предварительно переводит на другой язык, меняет твою оригинальную дорожку и выдает зрителю переведенную имитацию
Тут отдельный ВАУ в том, что в ходе имитации звуков она оставляет ТВОЙ ГОЛОС. То есть блогер говорит на незнакомом ему языке на уровне носителя, без акцента. Это очень прикольно. Очень киберпанково и вообще прям слов нет, крч.
Мне лично очень интересно, когда на нашем канале такую фичу раскатают, и я смогу услышать свою же английскую речь без акцента. Ну или японскую.
А пока у нас такого нет, можете заценить у американского Вилсакома. Прям попрыгайте по аудиодорожкам. Даже на русском говорит прекрасно
https://youtu.be/jXJODqfaJto?si=MInGXsPmwP18bQb6
UPD: по предыдущей ссылке аудио переведено отдельно… но тоже в ИИ сервисе. Не человеком. И вставлено благодаря фиче мультидорожек от ютуба
Ютубовский же перевод можно посмотреть тут https://youtu.be/AHDvVhfU1Og?si=pqjKkrFLTk47rRQy
Там языков больше, но качество пока хуже. Ключевое - пока
Ютуб начал раскатывать автоматический дубляж в видео. Еще раз: АВТОМАТИЧЕСКИЙ ПЕРЕВОД твоей аудиодорожки.
То есть ты загружаешь свою обычную дорожку, где ты говоришь, например, на русском языке. Программулина ютуба каким-то магическим образом распознает звуки, которые ты говоришь.
Затем эти звуки она умеет имитировать, как умный попугай. А точнее - не просто имитировать, а предварительно переводит на другой язык, меняет твою оригинальную дорожку и выдает зрителю переведенную имитацию
Тут отдельный ВАУ в том, что в ходе имитации звуков она оставляет ТВОЙ ГОЛОС. То есть блогер говорит на незнакомом ему языке на уровне носителя, без акцента. Это очень прикольно. Очень киберпанково и вообще прям слов нет, крч.
Мне лично очень интересно, когда на нашем канале такую фичу раскатают, и я смогу услышать свою же английскую речь без акцента. Ну или японскую.
А пока у нас такого нет, можете заценить у американского Вилсакома. Прям попрыгайте по аудиодорожкам. Даже на русском говорит прекрасно
https://youtu.be/jXJODqfaJto?si=MInGXsPmwP18bQb6
UPD: по предыдущей ссылке аудио переведено отдельно… но тоже в ИИ сервисе. Не человеком. И вставлено благодаря фиче мультидорожек от ютуба
Ютубовский же перевод можно посмотреть тут https://youtu.be/AHDvVhfU1Og?si=pqjKkrFLTk47rRQy
Там языков больше, но качество пока хуже. Ключевое - пока
Я планировал начать с пайплайнов, но решил: давайте сначала разберемся с самой аббревиатурой CI/CD. Фишка в том, что под этими аббревиатурами подразумевают уже не то, что изначально закладывалось. Сейчас при упоминании CI/CD в голове всплывают скорее системы GitLab CI, Actions, Kubernetes или Docker. Однако все эти системы на самом деле лишь вспомогательные инструменты.
Continuous Integration — постоянная интеграция. Возникает вопрос: интеграция чего во что? Мы все работаем с кодом и, вероятнее всего, работаем в какой-то команде. Когда мы делаем какие-то изменения, то должны эти изменения распространить на других участников команды, а также получить изменения от них.
Сейчас для этого повсеместно используется Git. У тебя есть локальная версия кода, изменения в которой ты отправляешь на удаленный сервер. Другими словами, ты "интегрируешь" свои изменения с изменениями других участников.
Понимаете суть? Если у тебя настроен Git и есть практика условно раз в день отправлять свои изменения и получать изменения от остальных членов команды, у тебя уже в некотором смысле есть CI.
Вокруг этой идеи затем строится процесс, чтобы правильно внедрить наши изменения: хорошо бы их сначала проверить — прогнать линтер, прогнать тесты, сделать сборку. Ну и еще перед интеграцией наших изменений, чтобы наша команда эти изменения просмотрела, отсюда мы получаем код-ревью.
Continuous Delivery — постоянное развертывание. Этот принцип уже исходит из следующей проблемы. Вот есть разработка, которая пишет код, создает систему. И есть команда, отвечающая за развертывание. Проблема в коммуникации между этими двумя группами: одна группа жалуется на "тупых админов", вторая — на "криворуких разработчиков".
Помимо этого, софт раньше поставлялся четкими версиями. Вот выпустили вы ПО версии 2, и все, ближайшие пару лет будете на ней сидеть. Ведь чтобы ее обновить, нужно, чтобы все самостоятельно обновились через покупку диска, либо, если мы говорим про серверы, админы накатили новую версию.
Разумеется, если ты сейчас будешь выпускать обновления раз в полгода, твой бизнес отправится по направлению нах*й. Отсюда рождаются два основных принципа:
👉 команда разработки должна участвовать в развертывании;
👉 наша кодовая база должна быть готова к развертыванию в любой момент времени.
Уже из этих принципов мы получаем подходы к работе с Git (православный trunk-based, а не загнивающий Git Flow), Docker, чтобы синхронизировать окружение разработки и развертывания, Kubernetes, чтобы он сам убрал старые инстансы и поднял новые, и все прочее, что относится к DevOps.
Continuous Integration — постоянная интеграция. Возникает вопрос: интеграция чего во что? Мы все работаем с кодом и, вероятнее всего, работаем в какой-то команде. Когда мы делаем какие-то изменения, то должны эти изменения распространить на других участников команды, а также получить изменения от них.
Сейчас для этого повсеместно используется Git. У тебя есть локальная версия кода, изменения в которой ты отправляешь на удаленный сервер. Другими словами, ты "интегрируешь" свои изменения с изменениями других участников.
Понимаете суть? Если у тебя настроен Git и есть практика условно раз в день отправлять свои изменения и получать изменения от остальных членов команды, у тебя уже в некотором смысле есть CI.
Вокруг этой идеи затем строится процесс, чтобы правильно внедрить наши изменения: хорошо бы их сначала проверить — прогнать линтер, прогнать тесты, сделать сборку. Ну и еще перед интеграцией наших изменений, чтобы наша команда эти изменения просмотрела, отсюда мы получаем код-ревью.
Continuous Delivery — постоянное развертывание. Этот принцип уже исходит из следующей проблемы. Вот есть разработка, которая пишет код, создает систему. И есть команда, отвечающая за развертывание. Проблема в коммуникации между этими двумя группами: одна группа жалуется на "тупых админов", вторая — на "криворуких разработчиков".
Помимо этого, софт раньше поставлялся четкими версиями. Вот выпустили вы ПО версии 2, и все, ближайшие пару лет будете на ней сидеть. Ведь чтобы ее обновить, нужно, чтобы все самостоятельно обновились через покупку диска, либо, если мы говорим про серверы, админы накатили новую версию.
Разумеется, если ты сейчас будешь выпускать обновления раз в полгода, твой бизнес отправится по направлению нах*й. Отсюда рождаются два основных принципа:
👉 команда разработки должна участвовать в развертывании;
👉 наша кодовая база должна быть готова к развертыванию в любой момент времени.
Уже из этих принципов мы получаем подходы к работе с Git (православный trunk-based, а не загнивающий Git Flow), Docker, чтобы синхронизировать окружение разработки и развертывания, Kubernetes, чтобы он сам убрал старые инстансы и поднял новые, и все прочее, что относится к DevOps.
Итак, на самом деле у меня сегодня день рождения. Я бы не стал об этом писать, потому что в целом для меня это не то чтобы особенный день. Ну да, чуть повышенное внимание, конечно, приятно, не буду скрывать, но все же, день как день.
Однако произошла прикольная штука. Ровно 5 лет назад я пытался написать диплом для магистратуры. Диплом был по теме, связанной со сверточными нейронными сетями. ChatGPT тогда не было, и реализацию я, разумеется, просто спиздил у более умного друга, но это не важно.
Я жутко прокрастинировал написание диплома, но писать все равно хотелось. Поэтому я написал письмо самому себе через пять лет, то есть в будущее.
Просто хотел поделиться некоторыми строками из него, чтобы похихикать вместе.
Ну, если, пройтись по всему письму, много чего я так и не успел сделать. Гребаные 120 кг, в этом году я их точно пожму! При этом многое сделал того, что не планировал, например, этот канал.
Тут должно быть какое-то пафосное заключение, но размер моего мозга по-прежнему конкурирует с орехом, поэтому просто лайк поставьте, и продолжим про CI говорить.
Однако произошла прикольная штука. Ровно 5 лет назад я пытался написать диплом для магистратуры. Диплом был по теме, связанной со сверточными нейронными сетями. ChatGPT тогда не было, и реализацию я, разумеется, просто спиздил у более умного друга, но это не важно.
Я жутко прокрастинировал написание диплома, но писать все равно хотелось. Поэтому я написал письмо самому себе через пять лет, то есть в будущее.
Просто хотел поделиться некоторыми строками из него, чтобы похихикать вместе.
Ну, если, пройтись по всему письму, много чего я так и не успел сделать. Гребаные 120 кг, в этом году я их точно пожму! При этом многое сделал того, что не планировал, например, этот канал.
Тут должно быть какое-то пафосное заключение, но размер моего мозга по-прежнему конкурирует с орехом, поэтому просто лайк поставьте, и продолжим про CI говорить.
Итак, погнали, что такое пайплайн и из чего состоит.
В разных CI системах эта сущность называется по-разному: пайплайн, build chain, workflow. Суть у всех одна, поэтому я буду использовать термин "пайплайн". Любой пайплайн состоит из трех базовых вещей:
👉 триггер – который запускает пайплайн
👉 job (он же Action, он же Build) – части пайплайна, в которых происходит работа, об этом позже
👉 связи между job – в какой последовательности запускать job, кто кого должен ждать
Триггер – отвечает за то, при каком событии стартует пайплайн. Разнообразие зависит от конкретной системы, но чаще всего триггеры привязаны к событиям в Git. CI система следит за изменениями в git и запускает пайплайны на разные события: пуш ветки, мерж ветки, пуш тега. Есть события на абстракции поверх git, например, создание мерж-реквеста. Помимо этого есть шедулинг (запуск в определенное время), ручной запуск по кнопке, запуск по API и всякие вебхуки, которые позволяют подключать сторонние системы.
Job – атомарная единица пайплайна, в которой и происходит работа. В 99% случаев это просто запуск какого-то скрипта в нужном окружении. Саму по себе Job можно представить как функцию. Есть данные на вход, есть данные на выход. Job может быть без сайд-эффектов, а может что-то изменять вовне, например, отправлять сборку в сторы или пушить докер-образ.
Связи между Job. Решил выделить в отдельный пункт, потому что это довольно важная часть, от этого зависит нагрузка на инфраструктуру. Связи позволяют задать зависимости между Job, указать, нужно ли скачивать артифакты от предыдущей Job и что делать, если предыдущая Job упала.
Если собрать все это вместе, то получаем, что сам по себе пайплайн — это просто коллекция job, которые среагировали на какой-то триггер, выстроились в нужный порядок и были запущены в едином контексте.
В разных CI системах эта сущность называется по-разному: пайплайн, build chain, workflow. Суть у всех одна, поэтому я буду использовать термин "пайплайн". Любой пайплайн состоит из трех базовых вещей:
👉 триггер – который запускает пайплайн
👉 job (он же Action, он же Build) – части пайплайна, в которых происходит работа, об этом позже
👉 связи между job – в какой последовательности запускать job, кто кого должен ждать
Триггер – отвечает за то, при каком событии стартует пайплайн. Разнообразие зависит от конкретной системы, но чаще всего триггеры привязаны к событиям в Git. CI система следит за изменениями в git и запускает пайплайны на разные события: пуш ветки, мерж ветки, пуш тега. Есть события на абстракции поверх git, например, создание мерж-реквеста. Помимо этого есть шедулинг (запуск в определенное время), ручной запуск по кнопке, запуск по API и всякие вебхуки, которые позволяют подключать сторонние системы.
Job – атомарная единица пайплайна, в которой и происходит работа. В 99% случаев это просто запуск какого-то скрипта в нужном окружении. Саму по себе Job можно представить как функцию. Есть данные на вход, есть данные на выход. Job может быть без сайд-эффектов, а может что-то изменять вовне, например, отправлять сборку в сторы или пушить докер-образ.
Связи между Job. Решил выделить в отдельный пункт, потому что это довольно важная часть, от этого зависит нагрузка на инфраструктуру. Связи позволяют задать зависимости между Job, указать, нужно ли скачивать артифакты от предыдущей Job и что делать, если предыдущая Job упала.
Если собрать все это вместе, то получаем, что сам по себе пайплайн — это просто коллекция job, которые среагировали на какой-то триггер, выстроились в нужный порядок и были запущены в едином контексте.
Итак, «Любовь, смерть и роботы», 4-й сезон
У Netflix есть интересная тенденция в отношении этого произведения: все чётные сезоны получаются ну очень сомнительными.
Первый сезон – просто идеальный для всех техногиков и любителей фантастики. Каждая серия – настоящее произведение искусства, каждая серия удивляля. Было сложно предсказать, чем всё закончится. Чего только стоит эпизод про йогурт, который захватил мир!
Во втором сезоне авторы ушли в сторону отсылок к другим произведениям: «Терминатор», «Хроники Риддика», «Гаттака», «О дивный новый мир». Ещё добавили троллинг медиа – серия с великаном которая показывает, как быстро мы забываем о крупных новостях. Если в первом сезоне каждая серия удивляла, то во втором создаётся ощущение, что всё это ты уже где-то видел. Из-за этого многие бросили сериал именно на втором сезоне. Среди моих знакомых для многих стало новостью, что третий сезон уже давно вышел.
Третий сезон очень напоминает первый. Создатели, видимо, прислушались к отзывам на второй сезон и просто сделали хорошие, уникальные истории. Вернули трёх роботов, которые всем так полюбились. Поэтому, если вдруг вы его не смотрели – третий сезон крайне рекомендую.
Недавно вышел четвёртый сезон, и он сука странный. Если во втором сезоне ощущалась вторичность, то здесь кажется, что все сюжеты писала нейросеть. В предыдущих сезонах каждая серия была полноценной историей: с началом, развитием и концовкой. А в четвёртом сезоне как будто есть только начало. Мне понравилась только одна серия, тогда как даже во втором, очень сомнительном, мне понравились как минимум две.
Короче, надеюсь, у сериала будут хорошие просмотры, и они всё-таки сделают пятый сезон. Если я хорош в экстраполяции, он должен быть топ.
У Netflix есть интересная тенденция в отношении этого произведения: все чётные сезоны получаются ну очень сомнительными.
Первый сезон – просто идеальный для всех техногиков и любителей фантастики. Каждая серия – настоящее произведение искусства, каждая серия удивляля. Было сложно предсказать, чем всё закончится. Чего только стоит эпизод про йогурт, который захватил мир!
Во втором сезоне авторы ушли в сторону отсылок к другим произведениям: «Терминатор», «Хроники Риддика», «Гаттака», «О дивный новый мир». Ещё добавили троллинг медиа – серия с великаном которая показывает, как быстро мы забываем о крупных новостях. Если в первом сезоне каждая серия удивляла, то во втором создаётся ощущение, что всё это ты уже где-то видел. Из-за этого многие бросили сериал именно на втором сезоне. Среди моих знакомых для многих стало новостью, что третий сезон уже давно вышел.
Третий сезон очень напоминает первый. Создатели, видимо, прислушались к отзывам на второй сезон и просто сделали хорошие, уникальные истории. Вернули трёх роботов, которые всем так полюбились. Поэтому, если вдруг вы его не смотрели – третий сезон крайне рекомендую.
Недавно вышел четвёртый сезон, и он сука странный. Если во втором сезоне ощущалась вторичность, то здесь кажется, что все сюжеты писала нейросеть. В предыдущих сезонах каждая серия была полноценной историей: с началом, развитием и концовкой. А в четвёртом сезоне как будто есть только начало. Мне понравилась только одна серия, тогда как даже во втором, очень сомнительном, мне понравились как минимум две.
Короче, надеюсь, у сериала будут хорошие просмотры, и они всё-таки сделают пятый сезон. Если я хорош в экстраполяции, он должен быть топ.
Dev Easy Notes pinned «По многочисленным заявкам (одной) я решил сделать серию постов про то, с чем в основном работаю последние несколько лет, а именно про CI/CD. Расскажу в целом про базу для тех, кто вообще это не трогал: 👉 Что такое пайплайн из чего состоит 👉 Как запускаются…»