А почему станцию топят одним куском, а не расстыковывают на несколько фрагментов и не сводят с орбиты по одному? По идее они так должны сгореть почти полностью и не падать большими кусками в океан.
Ну атмосфера на луне все же имеется, правда сильно разряженная и почти не оказывает на нее влияние, но она все же есть. Поэтому не стоит говорить о вакууме.
Ровер «Юйту-2», так же складывает свои солнечные панели
А зачем? Ночь же короткая, не думаю, что много пыли осядет или в этом есть какой-то дополнительный смысл? Просто в какой-то момент может не раскрыться батарея из-за механического износа.
На сколько я помню, каждая транзакция стоит немного газа, кто будет платить за это? Ну и еще один момент сдается мне вы не оптимизировали по критерию уменьшения использования его для снижения стоимости.
Везде где я работал, документация была краеугольным камнем + дополнительно всегда требовалось документировать код продукта и тестов. У меня даже привычка выработалась, начинаю писать функцию, сразу пишу ее шапку в которой описываю для чего она нужна, все входные и выходные параметры. В итоге это занимает минимум времени, зато потом если возврщаюсь к ней — все прозрачно. Поэтому страннослышать, что где-то нет документации. Но это скорее мой опыт и у кого-то может быть другой. Не скрою часто встречал документацию для галочки особенно на наших оборонных предприятиях и приходилось из них ее клещами вытаскивать с тех пор зарекся работать в проектах с такими закзчиками.
В Xaomi аналогично! Когда сдохнет буду брать что-то друго именно по этой причине, причем сначал их было мало, но потом они стали апгрейдить MUI или как она там называется и их количество стало приростать. Короче в топку.
Если не ошибаюсь подобную встречал на LeetCode. Или Cracking Code Interview. Вообще имхо доводить на бумажке или доске до состояния компилируется ИМХО все же не правильно, я, например, могу от волнения тупо забыть методы из stl, какие в них параметры передаются, порядок, что выдают на гору. Мне кажется во всех подобных задачах при решении у доски важен именно диалог, который дает понять как у человека с алгоритмизацией и мышлением. А вот если уже комп дают, то можно уже смотреть с точки зрения компилирования, но там и ide помогает.В таких случаях я, например, начинал писать с юнит тестов (TDD), а потом итеративно писал алгоритм и придумывал дополнительные кейсы после того, как основная часть уже готова, но часто просили просто обсудить граничные условия, а не их реализацию и мы переходили к следующей.
P.S. Вакансия С++, просить написать на Python — будет странно смотреться))) Яб сильно задумался на месте собеседуемых, что от меня будут требовать в будущем.
Когда в переходах были еще ларьки — брал там ни разу не было такого. А вот на Али такого дерьмища полно. Сам лично напарывался на SD карту подобную.
Так что за переходы заступлюсь.
тридцаточка не та сумма которая будет радовать за такой якобы апгрейд. На новые подобные головы так и стоят, правда их в комплекте с другими опциями дают.
На сколько я понял статью, Code Analysis внедрялся как один из степов в пайплайне, т.е. выполнялся на бранче уже после выкладывания. Мы же использовали связку TFS+SonarQube, для того, чтобы делать Code Analysis во время вливания, т.е. изменения не вливались если изменения не надлежащего качества по мнению Sonar. А дальше выкатывание происходило отдельным процессом.
Возможно я не так понял процесс описанный в статье.
Когда мы внедрили SonarQube в легаси проект, мы не использовали его результаты для прекращения или продолжнения сборки при CI, НО! Все найденные ошибки просматривались в формате: Zero Tolerance к ошибкам типа Bug, Critical и Major, были заведены задачи для фикса подобных ошибок в течении двух спринтов, однако стоит отметить, что на 30 тысяч строк кода их было в районе 50 (багов было вообще штучно 2 или 3 не помню точно). В течении 2 спринтов мы избавились от этих трех и далее уже взялись за Minor, количество которых держали в пределах 100.
И кстати мы в итоге включили блокировку merge если наличествовали ошибки первых 3 типов и более 100 minor. Именно процесс CI был в итоге оставлен прежним.
Считаю такой подход тоже хорош, так как позволяет обойтись без дополнительных тикетов по результатам CI. Проблемы фиксились еще разработчиком до коммита в основную ветку.
Тоже самое, но K6-200. Мамка была ASUS, боготворил ее потом ибо после апгрейда биоса она увидела две планки по 32 мега и винчестер на 8 (точно уже не помню) Гигабайт. От S3 остались самые отвратительные впечатления, но это была видюха от формозы на этом чипсете, на матрокс денег не хватило. Драйвера устанавливались и с плясками и бубном ибо инет был не распростанен, я качал в универе драйвера, потом дома пробовал. Даже редхат 5 во вторую партицию установил, но он гад больше 640*480 не зотел разрешение ставить на моем 17 вьюсонике)))
В те времена пойти на Комтек было сродни попасть в число небожителей. Парень из группы работал в Кроке и у него было пара халявных билетов, ходли по очереди.
Помню ощущения были двоякие: да представляют вроде новое железо, но по фантастическим ценам.
Ходили слухи, что типа в последний день можно отхватить халявы, но никогда не подтверждались :)
До сих пор формат выставки мне не яснен ибо я не был целевой аудиторией в то время.
Комп я купил в итоге в 98 AMD K6-200.
Надо понимать, что все что вы делаете на работе за деньги работодателя принадлежит работодателю.
Поэтому переход со своим дашбордом в другую контору может расцениваться, как кража интелектуальной собственности.
Я конечно видел фразу типо восстановил по памяти, но в целом надо очень аккуратно с этим быть.
С другой стороны лейтмотив статьи — надо развиваться и это бесспорно.
А зачем? Ночь же короткая, не думаю, что много пыли осядет или в этом есть какой-то дополнительный смысл? Просто в какой-то момент может не раскрыться батарея из-за механического износа.
P.S. Вакансия С++, просить написать на Python — будет странно смотреться))) Яб сильно задумался на месте собеседуемых, что от меня будут требовать в будущем.
Так что за переходы заступлюсь.
Возможно я не так понял процесс описанный в статье.
И кстати мы в итоге включили блокировку merge если наличествовали ошибки первых 3 типов и более 100 minor. Именно процесс CI был в итоге оставлен прежним.
Считаю такой подход тоже хорош, так как позволяет обойтись без дополнительных тикетов по результатам CI. Проблемы фиксились еще разработчиком до коммита в основную ветку.
Помню ощущения были двоякие: да представляют вроде новое железо, но по фантастическим ценам.
Ходили слухи, что типа в последний день можно отхватить халявы, но никогда не подтверждались :)
До сих пор формат выставки мне не яснен ибо я не был целевой аудиторией в то время.
Комп я купил в итоге в 98 AMD K6-200.
Поэтому переход со своим дашбордом в другую контору может расцениваться, как кража интелектуальной собственности.
Я конечно видел фразу типо восстановил по памяти, но в целом надо очень аккуратно с этим быть.
С другой стороны лейтмотив статьи — надо развиваться и это бесспорно.