Cypress мне как не тестеру очень понравился низким порогом вхождения. Еще порадовала тулза Cypress Recorder.
Мне он нужен для автоматизации реальных химических тестов воды на ряд параметров, но софтина для тестов не имеет никакого API, и Cypress headless + Github Actions тут пришелся в самый раз.
Единственная претензия к docker образу Cypress — он весит 1.1GB и для запуска мелких тестов это немного overkill.
Я живу в Швеции и тоже получил сертификат EASA похожим путем как и автор.
Но данный сертификат разрешает летать дроном только в пределах видимости(VLOS), а дрон реально бывает уже не видно в 100 метрах. Даже если банально над деревьями полетел. И это очень спорный момент. Как доказывать гипотетическому правоохранителю что ты видишь дрон :).
Есть конечно возможность подать на разрешение летать вне зоны видимости BVLOS, но оно очень мудренное, требует составления сложных документов — operations manual, emergency response plan, maintenance instructions. Явно рассчитано на крупные компании и для обычных людей это сделать не так просто.
В европейских странах перед полетами важно ознакомится с местными правилами, и не полагаться на разрешенные зоны полета в официальной программе DJI, так как они могут сильно отличатся. Как правило есть как минимум одна официальная аппка для каждой страны, это самый проверенный вариант.
Особенно осторожным нужно быть при полетах в крупных городах, к примеру, какой нибудь невзрачный домик может оказаться посольством, и местные охранники могут вас задержать до приезда полиции…
На западе с фидбеком очень плохо, особенно в больших конторах. Некоторые даже пишут об этом явно в начале рекрутинг процесса, мол в случае отказа деталей «почему» раскрывать не будем. Кажется Amazon AWS таким страдал.
В прошлом на собеседованию в одну фирму среднего размера на собеседовании с технарями я даже вежливо попросил дать фидбек в случае отказа, мол интересно знать свои слабые стороны с точки зрения внешнего наблюдателя. Их, как мне кажется, эта просьба положительно настроила. Но меня туда взяли и фидбек не понадобился.
Статья зачетная как и для рекрутеров так и для самих DevOps. Вот бы большинство рекрутеров следовало этому. А то в профайле написано что всегда работал только с AWS и Linux, а рекрутеры иногда присылают роль по Azure+Windows и говорят что я отлично подхожу на эту роль, трудно прочитать что-ли пару строчек и не тратить ни свое ни мое время.
Понимаю автора. Но многие terraform эксперты рекомендуют избегать как remote-exec так и local-exec. По причине того что то, что делает local/remote-exec уже вне контроля terraform. Terraform plan уже не покажет что именно там сделает с инстансом exec. Что может однажды выстрелить в ногу. И дело тут не в Ansible.
А почему просто не создавать инстансы на базовом образе, а provision делать в userdata?
Userdata хорошо управляется с помощью terraform, а там внутри используйте хоть bash хоть ansible.
Логично, у каждого разные требования, нет универсальной автоматизации. Может в вашем случае просто продолжать пользоваться обычным выключателем? Ибо «выключать До открытия» двери это имхо очень сложный триггер.
Я с автоматизацией в санузлах поступил проще. У меня на двери датчик открытия и в комнате датчик движения. Свет просто включается если открылась дверь или сработал датчик движения. По прохождению 20 минут если движения не было — выключаем свет. Опытным путем было выяснено что больше 20 минут не нужно. Я тоже думал заморочится с датчиком объемного присутствия или дополнительного детектора движения, но посчитал что оно того не стоит — освещение светодиодное, и даже если свет будет выключен на 10 минут позже расход будет мизерный.
И не нужно заморачиватся со сложной логикой.
Если в кратце, то я как и автор волею судеб переметнулся в контракторы. Очередной рекрутер предложил контрактный вариант и я решил попробовать. Что удивило — процесс интервью для контрактников совсем другой, обычно это одно интервью непосредственно с командой и их начальником. Так я получил свой первый контракт в большую фирму, в которой обычный процесс для не-контракторов это 5 интервью и пару месяцев времени.
За Норвегию не скажу, но в Швеции была и есть волна избавления от контрактников в больших фирмах. Как правило сначала достойным контрактникам предлагают постоянную позицию, и они уже решают. Это больше коснулось девелоперов на популярных языках типа Java. Одна из причин — деньги, некоторые контрактники сидели на одном месте по много лет на рутинных задачах, а это ведь дорого для компаний.
Я же работаю в DevOps, а девопсы как раз пока хорошо подходят в качестве контрактников. Настроил процесс в компании — пошел дальше.
Поиск клиента осуществляется не напрямую, а через брокеров, у которых как правило куча связей с фирмами которым нужны контракторы. Напрямую найти контракт очень сложно, т.к. они даже не всегда публикуются.
Хороший вариант — найти в LinkedIn брокера специализирующего на контракторах для определенной страны. В моем случае первая брокерская фирма была как раз из UK.
Пишите в личку если интересны подробности.
Тоже являюсь фрилансером, но в Швеции.
У нас «большая» фирма это по сути акционерная компания.
Из плюсов такого фриланса является также то, что ты за счет своей компании можешь платить себе большую пенсию без урона зарплате, что хорошо на будущее.
У нас фрилансер имеет право получать раз в год дивиденды от фирмы(13я зарплата), которые составляют примерно 13k евро после налогов(если конечно эти деньги есть на балансе компании, а с налогами это 16k), можно и больше, но тогда растет налог на них.
Из минусов что могут в любой момент разорвать контракт, но если на балансе фирмы накопились деньги, то пока ищешь себе новый контракт — можешь продолжать платить себе зарплату. И в последнее время появилась тенденция в больших компаниях избавлятся от контрактников и набирать на постоянку.
В Бельгии есть что-то подобное?
к сожалению да, в «домашних» морях может быть более десятка видов. От самых простых в виде налета на стекле, до всяких нитчатых, слизи, в виде пузырьков. Одни из самых неприятных — динофлагелляты, они могут выделять токсины, ночной кошмар «моряков». У меня из-за их вспышки умерли все рыбы и крабы отшельники. А все потому что аквариум был не стабильный, и я как раз экспериментировал с освещением.
Последняя картинка в посте — это тесты Hanna Instruments, одни из самых лучших оптических тестов для морского аквариума. А еще они очень дорогие, но они очень облегчают жизнь «моряков». Там принцип такой что делаешь несколько манипуляций с пробой воды(добавляешь разные реактивы в разной последовательности) и потом окрашенный в пробирке раствор поменяешь в прибор. Он по цвету определяет точно значение. Но для автоматизации такое точно не подойдет :).
Посмотрите как устроены популярные аквариумные контроллеры для морского аквариума, например Apex neptune. Там в воду погружаются разного типа электродов, пока успешно ими меряются kH, PH, Кальций, Температура, Соленость. В принципе остальные параметры в реалтайме нет надобности мониторить и это очень напряжно. Даже электроды/пробы крутых производителей нужно калибровать почти каждый месяц и живут они не долго из-за агрессивности соленой воды :(.
У меня у самого нано риф, и контроллеры которые имеют больше двух электродов стоят от 500 евро, а нормальный набор и всю 1000, что является для меня отталкивающим фактором.
Самая важная автоматизация в морском аквариуме по мне — это долив осмотической воды. Вот тут я бы не доверился DIY решению. Уменьшение или повышение солености на 2гр на литр(из-за испарения или перелива) может привести к очень плохим последствиям для кораллов и рыб. Поэтому лучше купить брендовый автодолив, и он прослужит многие годы.
У меня автоматизация по этим причинам разнесена на независимые модули. Да, управление каждым компонентом в разном месте, например спектр и расписание лампы, автодозировка разных хим добавок, контроллер температуры — когда холодно включаем нагреватели, жарко — охладители.
Автоматизировать подмену воды считаю излишним, т.к. в морском рекомендуется менять максимум 10%. Т.е. если у вас будет 50 литров, 5 литров поменять минутное дело. Долгое тут — это почистить сам аквариум до подмены и собственно засолить новую воду для подмены. Тут автоматизация сильно не поможет.
Свет для пресноводного и морского аквариума — это две разные вселенные.
Особенно если хочется выращивать кораллы. Погуглите настройки популярной лампы AI Prime к примеру, там 7 разных спектров контролируется. Даже в дешевой китайской лампе будет минимум 4 вида светодиодов. Кораллы очень требовательны к свету. Еще дело в эстетике, в нано рифе лучше всего смотрятся флуоресцентные кораллы. А сделать такое освещение чтобы они и светились и чтобы было не вырвиглазно смотрелось как раз поможет светильник с гибкими настройками по спектрам.
Автору респект в стараниях.
Но имхо лампа в рифовом аквариуме — компонент очень важный, и неправильный выбор может привести ко многим проблемам как и с кораллами, рыбами, водорослями, планктоном.
Плюс морская живность гораздо дороже, и рисковать ей не так хочется.
В пресном все проще — ну максимум водорослями зарастет.
Знакома боль автора.
Сам пришел некогда в организацию подобного размера, с 300+ репами. Тоже было организовано с помощью Terraform в одной папке и с одним гигантским стейтом, terraform plan занимал пол часа плюс иногда обрывался из-за лимитов GitHub API. Также при добавлении/удалении юзера из команды(github_team_membership) из-за используемого count сначала все члены команды удалялись, потом добавлялись, что очень раздражало.
Решилось путем разделения Terraform кода в кучу подпапок — по командам с разными state.
CI детектит в каких папках произошли изменения, и там запускает terraform plan.
Если есть перекрестные связи между командами — решается с помощью чтения внешнего data.terraform_remote_state.
Проблему с github_team_membership + count помог решить terraform 0.12 for_each, теперь при добавления юзера в команду terraform делает атомарное изменение и не нужно всю команду каждый раз передобавлять.
Теперь изменения в даже в самой большой команде занимают не больше 1 минуты.
Удаление/добавление репосов и юзеров у нас запрещено на уровне GitHub организации и старые репосы Terraform просто архивирует.
Вполне рабочая схема.
Полез посмотреть код модуля на terraform, потому как Cloud Landing Zone — тема интересная и полезная для multi-account сетапа. Но Terraform кода я там и не нашел, модуль использует в основном абстракцию terrahub в формате yaml. Напоминает гибрид бульдога с носорогом.
Модуль по сути делает только local-exec, который запускает node, который запускает terrahub, который генерирует чистый terraform код и запускает terraform, ну вы поняли…
ИМХО то еще извращение. Yaml terrahub-а нагнетает тоску, т.к. очень напоминает Cloudformation.
Почему не создать модуль на чистом terraform?
Мне он нужен для автоматизации реальных химических тестов воды на ряд параметров, но софтина для тестов не имеет никакого API, и Cypress headless + Github Actions тут пришелся в самый раз.
Единственная претензия к docker образу Cypress — он весит 1.1GB и для запуска мелких тестов это немного overkill.
Но данный сертификат разрешает летать дроном только в пределах видимости(VLOS), а дрон реально бывает уже не видно в 100 метрах. Даже если банально над деревьями полетел. И это очень спорный момент. Как доказывать гипотетическому правоохранителю что ты видишь дрон :).
Есть конечно возможность подать на разрешение летать вне зоны видимости BVLOS, но оно очень мудренное, требует составления сложных документов — operations manual, emergency response plan, maintenance instructions. Явно рассчитано на крупные компании и для обычных людей это сделать не так просто.
В европейских странах перед полетами важно ознакомится с местными правилами, и не полагаться на разрешенные зоны полета в официальной программе DJI, так как они могут сильно отличатся. Как правило есть как минимум одна официальная аппка для каждой страны, это самый проверенный вариант.
Особенно осторожным нужно быть при полетах в крупных городах, к примеру, какой нибудь невзрачный домик может оказаться посольством, и местные охранники могут вас задержать до приезда полиции…
В прошлом на собеседованию в одну фирму среднего размера на собеседовании с технарями я даже вежливо попросил дать фидбек в случае отказа, мол интересно знать свои слабые стороны с точки зрения внешнего наблюдателя. Их, как мне кажется, эта просьба положительно настроила. Но меня туда взяли и фидбек не понадобился.
Статья зачетная как и для рекрутеров так и для самих DevOps. Вот бы большинство рекрутеров следовало этому. А то в профайле написано что всегда работал только с AWS и Linux, а рекрутеры иногда присылают роль по Azure+Windows и говорят что я отлично подхожу на эту роль, трудно прочитать что-ли пару строчек и не тратить ни свое ни мое время.
А почему просто не создавать инстансы на базовом образе, а provision делать в userdata?
Userdata хорошо управляется с помощью terraform, а там внутри используйте хоть bash хоть ansible.
И не нужно заморачиватся со сложной логикой.
За Норвегию не скажу, но в Швеции была и есть волна избавления от контрактников в больших фирмах. Как правило сначала достойным контрактникам предлагают постоянную позицию, и они уже решают. Это больше коснулось девелоперов на популярных языках типа Java. Одна из причин — деньги, некоторые контрактники сидели на одном месте по много лет на рутинных задачах, а это ведь дорого для компаний.
Я же работаю в DevOps, а девопсы как раз пока хорошо подходят в качестве контрактников. Настроил процесс в компании — пошел дальше.
Поиск клиента осуществляется не напрямую, а через брокеров, у которых как правило куча связей с фирмами которым нужны контракторы. Напрямую найти контракт очень сложно, т.к. они даже не всегда публикуются.
Хороший вариант — найти в LinkedIn брокера специализирующего на контракторах для определенной страны. В моем случае первая брокерская фирма была как раз из UK.
Пишите в личку если интересны подробности.
У нас «большая» фирма это по сути акционерная компания.
Из плюсов такого фриланса является также то, что ты за счет своей компании можешь платить себе большую пенсию без урона зарплате, что хорошо на будущее.
У нас фрилансер имеет право получать раз в год дивиденды от фирмы(13я зарплата), которые составляют примерно 13k евро после налогов(если конечно эти деньги есть на балансе компании, а с налогами это 16k), можно и больше, но тогда растет налог на них.
Из минусов что могут в любой момент разорвать контракт, но если на балансе фирмы накопились деньги, то пока ищешь себе новый контракт — можешь продолжать платить себе зарплату. И в последнее время появилась тенденция в больших компаниях избавлятся от контрактников и набирать на постоянку.
В Бельгии есть что-то подобное?
Посмотрите как устроены популярные аквариумные контроллеры для морского аквариума, например Apex neptune. Там в воду погружаются разного типа электродов, пока успешно ими меряются kH, PH, Кальций, Температура, Соленость. В принципе остальные параметры в реалтайме нет надобности мониторить и это очень напряжно. Даже электроды/пробы крутых производителей нужно калибровать почти каждый месяц и живут они не долго из-за агрессивности соленой воды :(.
У меня у самого нано риф, и контроллеры которые имеют больше двух электродов стоят от 500 евро, а нормальный набор и всю 1000, что является для меня отталкивающим фактором.
Самая важная автоматизация в морском аквариуме по мне — это долив осмотической воды. Вот тут я бы не доверился DIY решению. Уменьшение или повышение солености на 2гр на литр(из-за испарения или перелива) может привести к очень плохим последствиям для кораллов и рыб. Поэтому лучше купить брендовый автодолив, и он прослужит многие годы.
У меня автоматизация по этим причинам разнесена на независимые модули. Да, управление каждым компонентом в разном месте, например спектр и расписание лампы, автодозировка разных хим добавок, контроллер температуры — когда холодно включаем нагреватели, жарко — охладители.
Автоматизировать подмену воды считаю излишним, т.к. в морском рекомендуется менять максимум 10%. Т.е. если у вас будет 50 литров, 5 литров поменять минутное дело. Долгое тут — это почистить сам аквариум до подмены и собственно засолить новую воду для подмены. Тут автоматизация сильно не поможет.
Особенно если хочется выращивать кораллы. Погуглите настройки популярной лампы AI Prime к примеру, там 7 разных спектров контролируется. Даже в дешевой китайской лампе будет минимум 4 вида светодиодов. Кораллы очень требовательны к свету. Еще дело в эстетике, в нано рифе лучше всего смотрятся флуоресцентные кораллы. А сделать такое освещение чтобы они и светились и чтобы было не вырвиглазно смотрелось как раз поможет светильник с гибкими настройками по спектрам.
Автору респект в стараниях.
Но имхо лампа в рифовом аквариуме — компонент очень важный, и неправильный выбор может привести ко многим проблемам как и с кораллами, рыбами, водорослями, планктоном.
Плюс морская живность гораздо дороже, и рисковать ей не так хочется.
В пресном все проще — ну максимум водорослями зарастет.
Сам пришел некогда в организацию подобного размера, с 300+ репами. Тоже было организовано с помощью Terraform в одной папке и с одним гигантским стейтом, terraform plan занимал пол часа плюс иногда обрывался из-за лимитов GitHub API. Также при добавлении/удалении юзера из команды(github_team_membership) из-за используемого count сначала все члены команды удалялись, потом добавлялись, что очень раздражало.
Решилось путем разделения Terraform кода в кучу подпапок — по командам с разными state.
CI детектит в каких папках произошли изменения, и там запускает terraform plan.
Если есть перекрестные связи между командами — решается с помощью чтения внешнего data.terraform_remote_state.
Проблему с github_team_membership + count помог решить terraform 0.12 for_each, теперь при добавления юзера в команду terraform делает атомарное изменение и не нужно всю команду каждый раз передобавлять.
Теперь изменения в даже в самой большой команде занимают не больше 1 минуты.
Удаление/добавление репосов и юзеров у нас запрещено на уровне GitHub организации и старые репосы Terraform просто архивирует.
Вполне рабочая схема.
Модуль по сути делает только local-exec, который запускает node, который запускает terrahub, который генерирует чистый terraform код и запускает terraform, ну вы поняли…
ИМХО то еще извращение. Yaml terrahub-а нагнетает тоску, т.к. очень напоминает Cloudformation.
Почему не создать модуль на чистом terraform?