Местных инженеров не наймешь, они все заняты и получают 10...12k USD в месяц. В таких случаях запад прибегает к услугам OutSource формирований.
Мой случай. Из России на США (да, до сих пор). Фактически веду бэкенд одного финтех-стартапа. Такого жесткача, как в этой заметке, не наблюдал. По крайней мере не систематически. Да, у менеджмента бывают приступы микро- и макроменеджмента раз в несколько месяцев, но это терпимо, и проходит за неделю-другую. Прямой контакт с заказчиком - постоянно и без проблем. По технике всё в наших руках. Ночами не сижу. Нет, я не могу сказать, что всё прям клёво, можно накопать разных проблем, но они скорее будут разбросаны по углам комнаты, чем лежать большой кучей в центре.
Тонкомпенсация любому регулятору нужна, если речь о воспроизведении музыки. Менять громкость лучше в фонах, а не в децибелах. Потому что если это делать в децибелах (одинаково по всему спектру), то с падением громкости середина спектра начинает выпирать - такая же особенность слуха, как и логарифмическое восприятие звукового давления. Поэтому без тонкомпенсации не обойтись, если стоит задача сохранить тембральный баланс на разных уровнях громкости.
Окей, сижу краснею насколько я не в теме был. Но даже так, что мешает и в инфраструктурном репозитории собирать каждую среду отдельными бранчами, а не промоутить целиком develop в stage и потом в prod? Тогда специфика одной среды не будет перетекать в другую.
Курица - не птица, АСУТП - не программирование... Спокойно-спокойно, сам из АСУТП. Лет через 20 там обязательно будут бранчеваться и терраформить инфраструктуру кодом.
По состоянию на 2016-й, когда я ещё был занят в той сфере, там был жёсткий vendor lock-in. Хочешь побаловаться гитом? На, попробуй проект в бинарном формате и/или с графическими языками. Хочешь в другую IDE? На, попробуй проект в бинарном формате и/или с графическими языками. Хочешь портировать проект на другой контроллер? Написать автотесты? Ну вы поняли... А если ещё хоть какая-то мотивация осталась, то вот тебе вендорские расширения к IEC 61131-3, дружок; они не совместимы ни с чем, и только вендор знает что там у них под капотом. Короче, плохо всё.
когда ты читаешь "стартапы" в названии, первая мысль про команды профессионалов, которые разрабатывают что-то на грани новых технологий
Стартапы запускаются не только прожжёнными программистами и не только для них. В этих случаях код получается очень "бизнесовым", без всех этих ваших абстракций в самом коде и в процессах вокруг него.
Сам участвовал в переписывании таких стартапов когда код уже невозможно развивать дальше базовой реализации изначальной идеи. Заказчик приходил с backup.zip от предыдущей команды, и даже папочки /.git внутри не было (не значит, что всегда не было, но разбираться с этим уже никто не будет).
Допустим, мы выкатили изменения в develop-окружение, протестировали всё и хотим выкатиться в stage. Каким образом мы можем это сделать? У нас — GitOps, поэтому мы, очевидно, хотим по максимуму использовать git-подход, то есть выполнить merge кода из dev в stage.
Почему очевидно? Мне в какой-то момент стало неочевидно. Тогда я предложил команде перестать притворяться, что develop достаточно стабилен, чтобы целиком раскатывать его на stage и затем на prod. Он почти никогда не стабилен: туда постоянно выкатывают что-нибудь свежее и там всегда висит что-нибудь недоделанное, а иной раз даже отложенное в долгий ящик. Кто-то предлагает обмазывать всё нестабильное feature-тогглами, но тогда код становится месивом из тогглов.
Короче, мы собираем stage из тех же самых веток, из которых собирается develop, но только после их адресного тестирования в develop. Уже потом тестируем stage в целом и раскатываем его на prod. А develop живёт практически как форк - он никуда не вмёрживается (кроме бранчей для разрешения конфликтов, но это другая история; в любом случае develop никогда не попадает в prod).
Естественно, это компромисс со своими минусами. Но он вполне покрывает условия с ограниченным числом сред, ручным тестированием (ибо пробелы в автотестах) и зависимыми командами (мобильщикам нужен свежий бэк). Сейчас хотим избавляться от этих статических сред (кроме прода, естественно) в пользу эфемерных. Типа создал PR - сразу получил в нём ссылку на отдельное окружение для тестирования. Дальше по желанию либо сразу в прод, либо накопить изменения в stage и уже потом в prod.
Короче, для меня теперь под большим вопросом очевидность проталкивания всей среды по этапам стабильности. И, возвращаясь к теме топика, такой подход исключает попадание develop-конфигурации в prod. Вполне можно рассмотреть. Не исключено также, что я несу чушь и заразил команду каким-то неортодоксальным пониманием develop/stage/prod, но в целом это сработало, и мы больше не ломаем голову относительно стабильности целых сред.
Угнать в смысле покататься, например: https://74.ru/text/gorod/2011/10/21/59029041/
Это даже не совсем проекция. То есть это такая же проекция, как на смартфон через зеркало смотреть.
То есть это широкий низкий дисплей с козырьком плюс небольшой проекционный сетап с водительской стороны?
Тогда почему её нет с самими дискетами? Они ведь тоже разного качества бывают (бывали).
Мой случай. Из России на США (да, до сих пор). Фактически веду бэкенд одного финтех-стартапа. Такого жесткача, как в этой заметке, не наблюдал. По крайней мере не систематически. Да, у менеджмента бывают приступы микро- и макроменеджмента раз в несколько месяцев, но это терпимо, и проходит за неделю-другую. Прямой контакт с заказчиком - постоянно и без проблем. По технике всё в наших руках. Ночами не сижу. Нет, я не могу сказать, что всё прям клёво, можно накопать разных проблем, но они скорее будут разбросаны по углам комнаты, чем лежать большой кучей в центре.
Не нагугливается ничего. Можно какую-нибудь зацепку?Оно? https://www.youtube.com/watch?v=dhGl30Ll4vAГПТ?
Хорошая вещь была чтобы над одноклассниками в кабинете информатики издеваться.
Тонкомпенсация любому регулятору нужна, если речь о воспроизведении музыки. Менять громкость лучше в фонах, а не в децибелах. Потому что если это делать в децибелах (одинаково по всему спектру), то с падением громкости середина спектра начинает выпирать - такая же особенность слуха, как и логарифмическое восприятие звукового давления. Поэтому без тонкомпенсации не обойтись, если стоит задача сохранить тембральный баланс на разных уровнях громкости.
Тот же самый документ, соседний раздел - RUB как рубль.
Пока нельзя. Коробки автоматической нет.
Такое себе это ничего не делать и ждать всего официального-преофициального. Да и про массовый выпуск никто не говорит ещё.
Вот: https://github.com/commaai/openpilot/tree/master/selfdrive/car Вот ещё: https://github.com/commaai/opendbc В целом реверс-инжиниринг протоколов электроусилителя руля и гидроблока тормозов это детский лепет по сравнению с разработкой беспилотной части. А педаль газа это вообще резистор обычный.
А зачем там какое-то особенное сотрудничество? Какое значение имеет марка моторизованной тележки для отработки технологии?
Окей, сижу краснею насколько я не в теме был. Но даже так, что мешает и в инфраструктурном репозитории собирать каждую среду отдельными бранчами, а не промоутить целиком develop в stage и потом в prod? Тогда специфика одной среды не будет перетекать в другую.
Курица - не птица, АСУТП - не программирование... Спокойно-спокойно, сам из АСУТП. Лет через 20 там обязательно будут бранчеваться и терраформить инфраструктуру кодом.
По состоянию на 2016-й, когда я ещё был занят в той сфере, там был жёсткий vendor lock-in. Хочешь побаловаться гитом? На, попробуй проект в бинарном формате и/или с графическими языками. Хочешь в другую IDE? На, попробуй проект в бинарном формате и/или с графическими языками. Хочешь портировать проект на другой контроллер? Написать автотесты? Ну вы поняли... А если ещё хоть какая-то мотивация осталась, то вот тебе вендорские расширения к IEC 61131-3, дружок; они не совместимы ни с чем, и только вендор знает что там у них под капотом. Короче, плохо всё.
За эмбеддеров ничего не скажу, впрочем.
Стартапы запускаются не только прожжёнными программистами и не только для них. В этих случаях код получается очень "бизнесовым", без всех этих ваших абстракций в самом коде и в процессах вокруг него.
Сам участвовал в переписывании таких стартапов когда код уже невозможно развивать дальше базовой реализации изначальной идеи. Заказчик приходил с backup.zip от предыдущей команды, и даже папочки /.git внутри не было (не значит, что всегда не было, но разбираться с этим уже никто не будет).
CVS
Почему очевидно? Мне в какой-то момент стало неочевидно. Тогда я предложил команде перестать притворяться, что develop достаточно стабилен, чтобы целиком раскатывать его на stage и затем на prod. Он почти никогда не стабилен: туда постоянно выкатывают что-нибудь свежее и там всегда висит что-нибудь недоделанное, а иной раз даже отложенное в долгий ящик. Кто-то предлагает обмазывать всё нестабильное feature-тогглами, но тогда код становится месивом из тогглов.
Короче, мы собираем stage из тех же самых веток, из которых собирается develop, но только после их адресного тестирования в develop. Уже потом тестируем stage в целом и раскатываем его на prod. А develop живёт практически как форк - он никуда не вмёрживается (кроме бранчей для разрешения конфликтов, но это другая история; в любом случае develop никогда не попадает в prod).
Естественно, это компромисс со своими минусами. Но он вполне покрывает условия с ограниченным числом сред, ручным тестированием (ибо пробелы в автотестах) и зависимыми командами (мобильщикам нужен свежий бэк). Сейчас хотим избавляться от этих статических сред (кроме прода, естественно) в пользу эфемерных. Типа создал PR - сразу получил в нём ссылку на отдельное окружение для тестирования. Дальше по желанию либо сразу в прод, либо накопить изменения в stage и уже потом в prod.
Короче, для меня теперь под большим вопросом очевидность проталкивания всей среды по этапам стабильности. И, возвращаясь к теме топика, такой подход исключает попадание develop-конфигурации в prod. Вполне можно рассмотреть. Не исключено также, что я несу чушь и заразил команду каким-то неортодоксальным пониманием develop/stage/prod, но в целом это сработало, и мы больше не ломаем голову относительно стабильности целых сред.
Где она ставится в ущерб альтернативам?