Ну, это такое. Лично я считаю, что TDD — это overhyped фигня, которая не везде подходит, а часто написание тестов «после» намного удобнее и дает большее покрытие.
А тестирование некоторых вещей — долго и дорого, по сравнению со стоимостью/сроками решаемой бизнес задачи.
Затем, что можно поторговаться. Берете офер у компании А, говорите, что подумаете и подождете оферы от компании Б и В. Потом, когда рекрутер компании А Вам снова позвонит, скажите, что Вы еще не собрали все оферы, но есть уже офер от компании Б, который немного выше (есть какие-то более приятные бенефиты и т.п.). Спросите, может ли компания А заматчить офер компании Б/предложить какие-то дополнительные бенефиты?" И вот это все. И там можно по кругу поднимать ставки, если у Вас есть соответствующие скилы. Если Вы действительно ценный специалист, компании будут готовы поторговаться, потому что искать кадры — долго и дорого.
Если Вы готовы принимать первый же офер не торгуясь, то, да, из трех интервью Вы, скорее всего, одно да пройдете. А если хотите поторговаться, то нужно иметь хотя бы офера три. Чтобы их получить надо будет сходить на 5-10 интервью.
Но после 10+ лет в продакшене, думаете, мне интересно готовить этот непотреб, который даже не служит задаче, которую, якобы, должен решать? Нет.
Так никто не заставляет. Можете сидеть на попе ровно на своем текущем месте, «крутить свою гайку» и по вечерам отдыхать на диване, потягивая пивко.
Вы даже, скорее всего, без труда сможете найти подобную Вашей работу в небольших конторах. Но большие конторы выберут кандидатов пободрее. Потому что могут.
У меня раньше тоже было такое отношение к собеседующему, типа, «меня оценивают», «ему нельзя доверять», «все советы интервьюера будут засчитаны не в мою пользу, если я ими воспользуюсь, ибо будет выглядеть как подсказка». И все поменялось, когда я перестал бояться интервьюеров и относиться к ним как к своим коллегам, где вы вместе на собеседовании пытаетесь решить общую задачу. Также, есть возможность показать свои софт скилы, как вы умеете слушать и общаться с другими, воспринимать критику.
Бывает, конечно, когда интервьюер &удак и нормальный диалог с ним трудно построить. Но тогда и Вам стоит задуматься: а хотите ли вы работать с такими &удаками в одной компании. Интервью — это обоюдный процесс: они оценивают Вас, Вы — их. Им тоже важно заинтересовать придти работать к ним в компанию (и сэкономить немного на Вашей зарплате, потому что работать с &удаками люди идут только если там платят больше других).
И если бы у меня, даже на привычной мне работе, постоянно стояли бы сзади и смотрели бы, как я пишу код, я бы тоже долго не задержался. Слава-богу, такого нигде нет.
Ойли! А вы не слышали про парное программирование? Очень модная фигня, кстати. Не все это делают, но те, кто делают, очень этим гордятся.
Если человек не имеет привычку часто менять работу, или просто часто ходит на собеседования, шансы на успешное прохождение лайф-кодинга и алгоротмичных задач весьма низки.
Еще раз: к собеседованиям надо готовиться. Это не так, что сегодня вместо работы пошел на собеседование, а завтра — опять на работу. В хорошие компании люди по полгода готовятся к собеседованиям, по вечерам решая задачи на LeetCode, прорабатывая дизайны разных систем для дизайн интервью, делая mock-интервью.
Говорит ли это как-либо о ровне навыков человека? Я не уверен в этом.
Может, говорит, может — не говорит. Можно долго рассуждать на эту тему, но те, кто готовятся, попадают в хорошие компании на хорошие зарплаты, а те, кто не готовится, продолжают рассуждать, что это не показатель.
Кто-то может считать другие знания элементарными, которыми Вы не обладаете.
Конечно! Кто-то, может, отличный повар или умеет ездить на лошади. И это замечательно! Но на собеседовании конкретные люди ищут конкретных программистов в свою команду, чтобы писать конкретные проекты. И у них могут быть конкретные требования, под которые не подходят большинство программистов. И можно сколько угодно обижаться, что у Вас на собеседовании спросили написать какую-то дичь типа фильтра Калмана… или, скажем, стэк. Просто Вы, скорее всего, туда не подходите.
Звучит так, как будто обход дерева — это что-то невообразимое, хотя деревья встречаются в повседневном программировании постоянно. Есть какой-то минимальный уровень проблем, на решение которых у программиста не должно уходить время. Если на каждый чих вы лезете в Google и StackOverflow, то Ваша кандидатура будет сильно проигрывать людям, которые сразу все знают.
Спешу Вас расстроить: знание тонкостей IDE — это далеко не самый важный навык программиста. Важно — быстро выдавать качественный результат. А в чем человек работает не имеет значения, пусть хоть в блокноте.
Чем писание кода на доске не лайвкодинг?! В период пандемии теперь все интервью — лайв кодинг: пишете в каком-нибудь coderpad, там же и запускаете. Решение задачек на доске/блокноте — это повсеместные практики интервью для программистов. И да, к этому надо готовиться, тренироваться. Есть задачи на знание алгоритмов и структур данных, есть — на реализацию (как у автора).
В винде можно поставить софтинку (типа такой https://github.com/fabsenet/adrilight), она будет грабить экран прямо на месте, никаких дублирований и vga. Потом подключают arduino nano по USB, которая по нехитрому протоколу получает цвета и выставляет их на rgb ленте.
Я не любитель писать гайды. Ставил на дефолтный Raspbian, потом Hyperion.NG — у них есть гайд как собрать (включая однострочник, который скачивает скрипт для сборки из интернетов). Дальше — в UI методом тыка.
Насчет RPi PWM — вот здесь можно почитать. По сути, там используется DMA и PWM для отсылки сигналов.
Что конкретно интересует? Если хочется просто подсветку, то достаточно поставить Hyperion.NG и настроить его использовать RPi PWM способ управления подсветкой.
Я поверх этого наворчивал всякие дополнительную функциональность. Например, одно из неудобств сетапа (и, думаю, в HDMI-to-AV будет то же самое) — RPi не знает, когда телевизор выключен. Поэтому подсветка светит всегда. Надо было как-то понимать, когда телевизор включен. Поэтому я подключил RPi к телевизору посредством HDMI (что, немного неудобно, потому что съедает один HDMI вход на телевизоре), и использовал скрипт на Python для мониторинга HDMI CEC, понимал, когда телевизор вылкючился/включился и посылал команду Hyperion.NG включить/выключить подсветку.
Потом я использовал HAP-python для написания программы, которая притворяется телевизором для Apple HomeKit (фреймворк домашней автоматизации от Apple) и использовал YS-IRTM для посылки IR команд телевизору, чтобы включать/выключать/менять громкость. Также, поскольку у моего телевизора всего два HDMI входа (у меня что называется «Dumb TV») и один уже занят RPi, у меня стоит HDMI свитч, чтобы переключаться между источниками и у него тоже есть ИК пульт. Поэтому, я использую YS-IRTM для посылки команд туда (по команде от HomeKit). Это все написано на Python.
Ну, это лишь говорит о том, что Вам повезло с железом. Я отсматривал захваченную картинку и во-первых, она была низкого разрешения, во-вторых при резкой смене кадра там наблюдались помехи (снег) на части картинки.
Все же, я всем, кто собирается повторить это, рекомендую брать нормальный девайс захвата. Это будет слегка дороже, но значительно меньше возни и гемора. У меня тоже один блок питания (кажется, 5V 8A), от него запитывается RGB лента и малина (через пины). Девайс захвата запитывается по USB.
У меня телевизор включен постоянно, обычно там просто заставки Chromecast, но каждый вечер, когда комната в основном освещается экраном телевизора, оно создает приятную атмосферу. Уже месяцев 8 как я собрал, но все равно поражаюсь, насколько это приятно.
Поделюсь своим опытом. Я собирал честную подсветку, которая работает с любым сигналом. У меня есть Хромкаст, Xbox и Nintendo Switch и Apple TV, поэтому сетап с Kodi не подходил. Начинал с такой же схемы: HDMI сплиттер, HDMI -> AV конвертер, AV USB capture. С этим сетапом есть проблемы:
1. ОЧЕНЬ. МНОГО. ПРОВОДОВ. Да, HDMI сплиттер запитывается прямо с HDMI, это хорошо, но, например, HDMI -> AV надо запитывать отдельно (провод + блок питания). Также, отдельный HDMI кабель между сплиттером и конвертером, а так же RCA кабель между конвертером и AV capture донглом. Плюс, это три отдельных девайса, которые тоже занимают место (а если не хотите, чтобы донгл из RPi торчал, то надо еще и USB папа-мама удлинитель).
2. Не знаю как у автора, но у меня весь этот сетап давал очень плохую картинку, она заметно отставала и часто имела помехи.
В итоге я плюнул и купил нормальный HDMI capture девайс (на Амазоне ищется по «HDMI Capture,HDMI to USB 3.0»). Стоит эта балалайка $90, но после неудачи с предыдущим сетапом я был готов попробовать. И, о боже, насколько она лучше. Первое, она уже сама по себе — HDMI сплиттер, т.е. у нее есть HDMI вход и HDMI выход и она гонит сигнал со входа на выход. Также, USB кабелем подключаем к RPi и оно там видится как USB камера. Захват быстрый, задержка маленькая, минимум проводов, все компактно. Тем, кто намучается с предыдущим сетапом, рекомендую.
Далее, Hyperion. Я начинал с простого скрипта на OpenCV и питоне, чтобы считать цвета по краям и выдавать их на RGB ленту, но уперся в скорость и перешел на Hyperion. Лично меня Hyperion всегда отталкивал вот этими костылями, что есть какой-то конфиг, но там хрен разберешься и надо качать стороннюю программу, чтобы этот конфиг генерить. Ладно. Потом уперся в то, что мой супер девайс захвата выдает картинку в формате, который Hyperion не умеет всасывать. Пришлось напилить новый драйвер для захвата через OpenCV (и, да, не благодарите, оно уже вмержено в мастер). Но пока я ходил за разработчиками и упрашивал их вмержить мой патч, они мне рассказали, что «забей ты на Hyperion, у нас теперь есть Hyperion.NG, новый, блестящий, и он из коробки умеет захватывать твои форматы». Действительно умеет, но там были другие грабли — драйвер управления RGB лентой через RPi PWM просто крэшился. Пришлось разбираться и чинить (патч уже в мастере).
Я всем рекомендую сразу брать Hyperion.NG, там есть встроенный web интерфейс (а также API) для настройки и управления, не надо делать этих приседаний с HyperCon.
Насчет ИК порта: я сам его не делал, у меня всегда работает режим с дублированием цветов края картинки, но я таки прикрутил ИК интерфейс для других нужд. Я считаю, проще вариант — взять готовый ИК декодер YS-IRTM. Единственный недостаток — он работает на 5V, а RPi пины — 3.3v, поэтому пришлось городить logic level shifter (и вот это станет барьером для многих хоббистов). Зато, там понятный serial интерфейс и есть возможность использовать его как передатчик (что я, собссно, и делаю, чтобы уметь включать/выключать ТВ и контроллировать громкость. Да. я в курсе, что это можно делать и через CEC, но мой CEC оказался обрезанным).
Писал я проект для себя, никак монетизировать его не собирался. Выложил в опенсорс и теперь у меня сообщество единомышленников, которые репортят, а иногда и чинят баги, добавляют новый функционал, советуют. Как следствие: улучшение мира и чувство самореализации. Не все можно измерить только деньгами.
Я нигде не говорил, что правка истории — это в публичных репозиториях. Ни в коем случае! Ваши коллеги потом ТАК нарукожопят, что исправлять будет уже намного дороже.
Насчет поиска комментов после переписывания истории — да, это проблемная часть практически во всех системах. Мы пользуемся BitBucket, там у пулреквестов есть вкладка Activity, которая показывает хронологию всех действий, включая комменты.
Также, мы часто стараемся записывать исправления как fixup коммиты, но не делать rebase. Тогда проверяющему проще посмотреть, какие были сделаны изменения. А перед мержем можно сделать git rebase -i и все fixup коммиты куда надо уйдут.
Есть еще Gerrit, который там как-то с этим борется, но интерфейс из 90х убивает все желание пользоваться этим.
А тестирование некоторых вещей — долго и дорого, по сравнению со стоимостью/сроками решаемой бизнес задачи.
Если Вы готовы принимать первый же офер не торгуясь, то, да, из трех интервью Вы, скорее всего, одно да пройдете. А если хотите поторговаться, то нужно иметь хотя бы офера три. Чтобы их получить надо будет сходить на 5-10 интервью.
Так никто не заставляет. Можете сидеть на попе ровно на своем текущем месте, «крутить свою гайку» и по вечерам отдыхать на диване, потягивая пивко.
Вы даже, скорее всего, без труда сможете найти подобную Вашей работу в небольших конторах. Но большие конторы выберут кандидатов пободрее. Потому что могут.
Бывает, конечно, когда интервьюер &удак и нормальный диалог с ним трудно построить. Но тогда и Вам стоит задуматься: а хотите ли вы работать с такими &удаками в одной компании. Интервью — это обоюдный процесс: они оценивают Вас, Вы — их. Им тоже важно заинтересовать придти работать к ним в компанию (и сэкономить немного на Вашей зарплате, потому что работать с &удаками люди идут только если там платят больше других).
Ойли! А вы не слышали про парное программирование? Очень модная фигня, кстати. Не все это делают, но те, кто делают, очень этим гордятся.
Еще раз: к собеседованиям надо готовиться. Это не так, что сегодня вместо работы пошел на собеседование, а завтра — опять на работу. В хорошие компании люди по полгода готовятся к собеседованиям, по вечерам решая задачи на LeetCode, прорабатывая дизайны разных систем для дизайн интервью, делая mock-интервью.
Может, говорит, может — не говорит. Можно долго рассуждать на эту тему, но те, кто готовятся, попадают в хорошие компании на хорошие зарплаты, а те, кто не готовится, продолжают рассуждать, что это не показатель.
Джавистов очень легко выявить: они без IDE ничего не могут.
Конечно! Кто-то, может, отличный повар или умеет ездить на лошади. И это замечательно! Но на собеседовании конкретные люди ищут конкретных программистов в свою команду, чтобы писать конкретные проекты. И у них могут быть конкретные требования, под которые не подходят большинство программистов. И можно сколько угодно обижаться, что у Вас на собеседовании спросили написать какую-то дичь типа фильтра Калмана… или, скажем, стэк. Просто Вы, скорее всего, туда не подходите.
Интересно почитать исследования на тему корреляции используемых средств разработки и способностями к командной разработке.
Спешу Вас расстроить: знание тонкостей IDE — это далеко не самый важный навык программиста. Важно — быстро выдавать качественный результат. А в чем человек работает не имеет значения, пусть хоть в блокноте.
Чем писание кода на доске не лайвкодинг?! В период пандемии теперь все интервью — лайв кодинг: пишете в каком-нибудь coderpad, там же и запускаете. Решение задачек на доске/блокноте — это повсеместные практики интервью для программистов. И да, к этому надо готовиться, тренироваться. Есть задачи на знание алгоритмов и структур данных, есть — на реализацию (как у автора).
В винде можно поставить софтинку (типа такой https://github.com/fabsenet/adrilight), она будет грабить экран прямо на месте, никаких дублирований и vga. Потом подключают arduino nano по USB, которая по нехитрому протоколу получает цвета и выставляет их на rgb ленте.
Насчет RPi PWM — вот здесь можно почитать. По сути, там используется DMA и PWM для отсылки сигналов.
Я поверх этого наворчивал всякие дополнительную функциональность. Например, одно из неудобств сетапа (и, думаю, в HDMI-to-AV будет то же самое) — RPi не знает, когда телевизор выключен. Поэтому подсветка светит всегда. Надо было как-то понимать, когда телевизор включен. Поэтому я подключил RPi к телевизору посредством HDMI (что, немного неудобно, потому что съедает один HDMI вход на телевизоре), и использовал скрипт на Python для мониторинга HDMI CEC, понимал, когда телевизор вылкючился/включился и посылал команду Hyperion.NG включить/выключить подсветку.
Потом я использовал HAP-python для написания программы, которая притворяется телевизором для Apple HomeKit (фреймворк домашней автоматизации от Apple) и использовал YS-IRTM для посылки IR команд телевизору, чтобы включать/выключать/менять громкость. Также, поскольку у моего телевизора всего два HDMI входа (у меня что называется «Dumb TV») и один уже занят RPi, у меня стоит HDMI свитч, чтобы переключаться между источниками и у него тоже есть ИК пульт. Поэтому, я использую YS-IRTM для посылки команд туда (по команде от HomeKit). Это все написано на Python.
Все же, я всем, кто собирается повторить это, рекомендую брать нормальный девайс захвата. Это будет слегка дороже, но значительно меньше возни и гемора. У меня тоже один блок питания (кажется, 5V 8A), от него запитывается RGB лента и малина (через пины). Девайс захвата запитывается по USB.
1. ОЧЕНЬ. МНОГО. ПРОВОДОВ. Да, HDMI сплиттер запитывается прямо с HDMI, это хорошо, но, например, HDMI -> AV надо запитывать отдельно (провод + блок питания). Также, отдельный HDMI кабель между сплиттером и конвертером, а так же RCA кабель между конвертером и AV capture донглом. Плюс, это три отдельных девайса, которые тоже занимают место (а если не хотите, чтобы донгл из RPi торчал, то надо еще и USB папа-мама удлинитель).
2. Не знаю как у автора, но у меня весь этот сетап давал очень плохую картинку, она заметно отставала и часто имела помехи.
В итоге я плюнул и купил нормальный HDMI capture девайс (на Амазоне ищется по «HDMI Capture,HDMI to USB 3.0»). Стоит эта балалайка $90, но после неудачи с предыдущим сетапом я был готов попробовать. И, о боже, насколько она лучше. Первое, она уже сама по себе — HDMI сплиттер, т.е. у нее есть HDMI вход и HDMI выход и она гонит сигнал со входа на выход. Также, USB кабелем подключаем к RPi и оно там видится как USB камера. Захват быстрый, задержка маленькая, минимум проводов, все компактно. Тем, кто намучается с предыдущим сетапом, рекомендую.
Далее, Hyperion. Я начинал с простого скрипта на OpenCV и питоне, чтобы считать цвета по краям и выдавать их на RGB ленту, но уперся в скорость и перешел на Hyperion. Лично меня Hyperion всегда отталкивал вот этими костылями, что есть какой-то конфиг, но там хрен разберешься и надо качать стороннюю программу, чтобы этот конфиг генерить. Ладно. Потом уперся в то, что мой супер девайс захвата выдает картинку в формате, который Hyperion не умеет всасывать. Пришлось напилить новый драйвер для захвата через OpenCV (и, да, не благодарите, оно уже вмержено в мастер). Но пока я ходил за разработчиками и упрашивал их вмержить мой патч, они мне рассказали, что «забей ты на Hyperion, у нас теперь есть Hyperion.NG, новый, блестящий, и он из коробки умеет захватывать твои форматы». Действительно умеет, но там были другие грабли — драйвер управления RGB лентой через RPi PWM просто крэшился. Пришлось разбираться и чинить (патч уже в мастере).
Я всем рекомендую сразу брать Hyperion.NG, там есть встроенный web интерфейс (а также API) для настройки и управления, не надо делать этих приседаний с HyperCon.
Насчет ИК порта: я сам его не делал, у меня всегда работает режим с дублированием цветов края картинки, но я таки прикрутил ИК интерфейс для других нужд. Я считаю, проще вариант — взять готовый ИК декодер YS-IRTM. Единственный недостаток — он работает на 5V, а RPi пины — 3.3v, поэтому пришлось городить logic level shifter (и вот это станет барьером для многих хоббистов). Зато, там понятный serial интерфейс и есть возможность использовать его как передатчик (что я, собссно, и делаю, чтобы уметь включать/выключать ТВ и контроллировать громкость. Да. я в курсе, что это можно делать и через CEC, но мой CEC оказался обрезанным).
Писал я проект для себя, никак монетизировать его не собирался. Выложил в опенсорс и теперь у меня сообщество единомышленников, которые репортят, а иногда и чинят баги, добавляют новый функционал, советуют. Как следствие: улучшение мира и чувство самореализации. Не все можно измерить только деньгами.
Насчет поиска комментов после переписывания истории — да, это проблемная часть практически во всех системах. Мы пользуемся BitBucket, там у пулреквестов есть вкладка Activity, которая показывает хронологию всех действий, включая комменты.
Также, мы часто стараемся записывать исправления как fixup коммиты, но не делать rebase. Тогда проверяющему проще посмотреть, какие были сделаны изменения. А перед мержем можно сделать git rebase -i и все fixup коммиты куда надо уйдут.
Есть еще Gerrit, который там как-то с этим борется, но интерфейс из 90х убивает все желание пользоваться этим.