Рил! Именно так и работает: если у вас есть полтриллиона выручки, то к вам в дверь ломятся полтриллиона адептов полутриллона next big thing, каждому из которых как раз ровно полтриллиона и не хватает для захвата вселенной.
Попробуйте вариант так назывыемого barn door tracker (https://en.wikipedia.org/wiki/Barn_door_tracker). Сорри, я не встречал его названия на русском языке: монтировка «амбарная дверь»? Даже лазером делать ничего не надо. Для ваших небольших выдержек должно получиться неплохо, как мне кажется.
Ну вообще-то реально закручивать гайки начали в 1903 году, когда запретили продажу скорострельного оружия. Были невнятные попытки и раньше, но не сработало. Потом в 1905 году, когда ужесточили и расширили ограничения. Не надо всё на большевиков валить.
А про "за небольшие деньги" - это как посмотреть... При стоимости убогого велодога в 5 рублей при средней зарплате рабочего в эти самые 5-15 рублей (в зависимости от года и региона цифры разные) - такие себе небольшие деньги. Сейчас оружие стоит реально дешевле относительно средней зарплаты в РФ.
Всё там есть. Предыдущий комментатор заблужадется. Я, собственно из-за аддонов и перешёл на FF: единственный, наверное, мобильный браузер, который позволяет поставить AdBlock. Да, порой подглюкивает. Но наличие адблока, как по мне, перевешивает другие проблемы.
Хе. У них много разных свистоперделок для разных случаев. Это уже давно не просто удалённый доступ типа RDP :)
И, кстати, весьма удобные митинги у них. В отличие от появившихся позже всяких zoom'ов есть весьма удобный шаринг экрана с возможностью управления компом (настраивается модератором). Мы активно использовали TeamViewer для обсуждения и тыканья мышой в нашей распределённой команде. Зачастую весьма удобно получив управление тупо показать на том компе, чем пытаться словами описать, что владелец должен сделать. Такой себе коллективный RDP :)
Но, начиная с версии 12 (если мне не отшибает память) в linux сломали работу митингов. А в 13-й вообще такой пункт меню убрали в линуксовой версии. Пользователи винды могут и сейчас, а вот линуксоидов лишили этой возможности. Просто патамушта.
Ну этот вопрос в туториале стоило бы разжевать подробнее, важный момент же.
Стоило бы разжевать, почему этого делать не стоит (реально не стоит?) и что получится, как избежать проблем.
В дополнение статье:
Просто так залить свою исправленную историю коммитов не получится. Сервер не примет. Решается использованием git push -f (force push). Тогда часть истории на сервере будет переписана. Но очень сильно и неприятно удивятся прочие разработчики при попытке сделать git pull, т.к. их локальная история очень сильно расходится с серверной. Тоже решаемо локально, но это потеря времени.
Таким образом, переписывать историю на сервере можно, если осторожно. Т.е., например, если разработчик один и никто больше репозиторий локально не имеет. Или в своей личной ветке, которую никто не использует. Или если сделать это очень быстро, пока другие разработчики, использующие ту же ветку, не обновились (т.е. не имеют локально оргинальных версии исправляемых коммитов). Или таки делать это после общения с коллегами, когда все пришли к выводу, что так лучше всего, и расхождение истории после git pull не станет для них неожиданным сюрпризом.
Можно.
1. Всё тот же git rebase -i
2. В редакторе у нужного коммита ставите e (edit)
3. Ребейз остановится на этом коммите.
4. Делаете ваши чёрные дела и продолжаете rebase (git rebase --continue).
Всё может быть гораздо проще: по моим наблюдениям, для ряда далёких от IT людей (особенно престарелых) «mail.ru» — это синоним слова «электронная почта».
Т.е. «net@mail.ru» некоторые могут искренне считать, что это значит «нет почты», только по-умному, по-компьютерному.
« Profiler является частью Android Studio и не имеет headless API, чтобы использовать его без UI. Да и едва ли это нужно. Он создан для поиска утечек памяти, анализа загрузки процессора и просмотра сетевой активности человеком. Не думаю, что это та часть процесса, которую нужно автоматизировать на CI. Если помечтать, то было бы прекрасно получать от билд-сервера отчеты по утечкам и неоптимальным алгоритмам, но сейчас это утопия из далекого будущего.»
Это он сам себе противоречит или я чего-то важного не понимаю?
Упс, сорри. Какая-то глубокая ветка получилась, я тут уже запутался, с кем дискутирую :)
То, что я написал в предыдущем комменте в большей части адресовано aikixd с учётом его предыдущих комментов. А вас я просто криво понял. Можно мой предыдущий коммент смело игнорировать. Ваши уточнения по делу.
Судя по вашей логике, даже в обычной ситуации роботу может показаться, что разметка пошла влево, и он спокойно заедет на встречку. Это то же самое, что процессор вашего компьютера будет ловить помехи и иногда считать 2+2=5, а вы будете усердно отлавливать баги в программе.
Это как раз таки штатная ситуация и фактически базовое требование для робота-автомобиля. Если он не сможет этого делать, то он не нужен как таковой вообще. Ну и к тому же, это не чисто программный, а программнно-аппаратный комплекс, т.е. пользуясь вашим примером, если процессор ловит помехи в штатном режиме, очевидно нам надо что-то менять в аппаратной части. А может и в программной.
Давайте уже считать, что ему гарантированно не может ничего «показаться», либо датчики работают, либо срабатывает аварийная остановка и дальнейшее движение будет невозможно. Как — это на совести инженеров, разрабатывающих все эти датчики.
Ну вот, я пытаюсь всё свести к реальности, а вы пытаетесь решать сугубо теоретическую проблему, которая, как мне кажется, на практике не возникнет :)
Не бывает идеальных сенсоров. Даже те, что имеются на голове у людей, имеют массу багов. Но даже если и предположить, что у нас есть такие сенсоры, это никак не отменяет другого аспекта, о чём я писал выше: алгоритмы разбора нештатных ситуаций если и возможно как-то формализовать, то это чертовски сложная задача. На практике, решение этой задачи превратится в странное непрогнозируемое устройство не имеющее практической цености.
Поясню на примере: у нас есть задача OCR, которая, как правило, решается с использованием нейронных сетей. Казалось бы, обучай нейронку всем существующим буквам всех существующих алфавитов и будет счастье, но, увы, нет: по факту у нас получится огромадная нейронная сеть, которая выдаёт ответы чуть ли не от балды, построив внутренние связи по каким-то совершенно диким критериям. Она начнёт путать иврит с клингонским, грузинкий с тайским и т.п. И кому она нужна? Генератор псевдослучайных чисел можно написать и с меньшими усилиями. :)
К слову, нейронные сети в критически важных продуктах не применяются: для серьёзных вещей требуются хоть какие-то гарантии, формальная верификация и т.п., чего нейронки предоставить не могут.
Подобная ситуация и с экспертной системой для автомобиля: обучив её на тысячах разных ситуаций мы получим что-то странное и ведущее себя непонятным образом. Как я уже говорил в предыдущем комменте, выпускать такое на дороги никто не решится.
Хотя, если продолжать упорствовать с этой идеей, то только тогда может возникнуть проблема, описанная в статье: нашу экспертную систему нужно обучать, что в такой-то ситуации мы давим котика, в такой-то ситуации можно выехать на тротуар, в такой-то — проскочить на красный и т.п.
Но, подытожив, необходимость в подобных размышлениях возникнет, если выполняются следующие условия:
* у нас есть идеальные датчики, которые не шумят, не ломаются и всегда всё прекрасно видят.
* у нас есть идеальная система распознавания сигнала с датчиков, которая всегда верно трактует полученные данные, легко отличает живого человека от рисунка на билборде, отличает упавший башенный кран от пролетающего мимо воздушного шарика и т.п.
* у нас есть идеальная экспертная система, которая в состоянии чётко различать огромное количество похожих ситуаций и принимать верное (или запрограммированное) решение.
Я думаю, что в данном случае есть слишном много «если», чтобы считать проблему, обсуждаемую в данном топике, хоть сколько нибудь близкой к реальности.
То есть он убъет пассажиров даже если тротуар свободен?
Да. Но в этом нет вины ни робота, ни авторов логики робота. Это так сказать, «обстоятельства непреодолимой силы», как, например, попадание метеорита в автомобиль.
Единственно верное решение в любой нештатной ситуации — торможение и ожидание инструкций от оператора-человека. Если оператор не выжил, ну что ж, не судьба :(
Но зато автомобиль гарантированно не выедет на тротуар из-за того, что в дальномер впилился майский жук, не проедет по заполненной людьми остановке автобуса из-за грязи на камере, не выедет на встречку из-за бага в замудрёной логике прошивки.
Сложные ситуации как с башенным краном весьма редки, анализ подобных ситуаций сложен и для человека. А создание робота в логику которого будут забиты тысячи и тысячи подобных нештатных ситуаций выльется в создание мега-глючного монстра, поведение которого никто не сможет предсказать.
Помимо этого есть ещё нюанс с достоверностью получаемых с сенсоров данных. Они никогда не достоверны на 100%. И никогда не будут. Логика предлагаемого вами поведения в случае с башенным краном означает, что на основании того, что роботу показалось, что есть внезапное препятсвие на дороге, он решил съехать на обочину, которая вроде как не остановка общественного транспорта и там кажется нет людей.
Никто не возьмёт на себя ответственность за разрешение такому агрегату перемещаться по дорогам общего назначения. Комиссии будущего просто напросто не сертифицируют робота, который может по каким-то непонятным, труднообъяснимым и сложно формализуемым причинам забить на ПДД.
И в общем-то самым демократичным производителем на этом фоне кажется Pebble, сразу подготовив стандартные крепления в версии Time под ремешки для своих пользователей.
Не совсем точно: уже самые первые их часики (которые просто Pebble) имели вполне стандартное крепление для ремешка.
Рил! Именно так и работает: если у вас есть полтриллиона выручки, то к вам в дверь ломятся полтриллиона адептов полутриллона next big thing, каждому из которых как раз ровно полтриллиона и не хватает для захвата вселенной.
Попробуйте вариант так назывыемого barn door tracker (https://en.wikipedia.org/wiki/Barn_door_tracker). Сорри, я не встречал его названия на русском языке: монтировка «амбарная дверь»? Даже лазером делать ничего не надо. Для ваших небольших выдержек должно получиться неплохо, как мне кажется.
Ну вообще-то реально закручивать гайки начали в 1903 году, когда запретили продажу скорострельного оружия. Были невнятные попытки и раньше, но не сработало. Потом в 1905 году, когда ужесточили и расширили ограничения. Не надо всё на большевиков валить.
А про "за небольшие деньги" - это как посмотреть... При стоимости убогого велодога в 5 рублей при средней зарплате рабочего в эти самые 5-15 рублей (в зависимости от года и региона цифры разные) - такие себе небольшие деньги. Сейчас оружие стоит реально дешевле относительно средней зарплаты в РФ.
Всё там есть. Предыдущий комментатор заблужадется. Я, собственно из-за аддонов и перешёл на FF: единственный, наверное, мобильный браузер, который позволяет поставить AdBlock. Да, порой подглюкивает. Но наличие адблока, как по мне, перевешивает другие проблемы.
Не, там просто своя атмосфера: фантазии на тему альтернативной истории.
А моделька забавная.
И, кстати, весьма удобные митинги у них. В отличие от появившихся позже всяких zoom'ов есть весьма удобный шаринг экрана с возможностью управления компом (настраивается модератором). Мы активно использовали TeamViewer для обсуждения и тыканья мышой в нашей распределённой команде. Зачастую весьма удобно получив управление тупо показать на том компе, чем пытаться словами описать, что владелец должен сделать. Такой себе коллективный RDP :)
Но, начиная с версии 12 (если мне не отшибает память) в linux сломали работу митингов. А в 13-й вообще такой пункт меню убрали в линуксовой версии. Пользователи винды могут и сейчас, а вот линуксоидов лишили этой возможности. Просто патамушта.
Это те ребята, что сломали 2 года назад поддержку митингов под linux и до сих пор их не починили?
Так себе пример :)
Стоило бы разжевать, почему этого делать не стоит (реально не стоит?) и что получится, как избежать проблем.
В дополнение статье:
Просто так залить свою исправленную историю коммитов не получится. Сервер не примет. Решается использованием git push -f (force push). Тогда часть истории на сервере будет переписана. Но очень сильно и неприятно удивятся прочие разработчики при попытке сделать git pull, т.к. их локальная история очень сильно расходится с серверной. Тоже решаемо локально, но это потеря времени.
Таким образом, переписывать историю на сервере можно, если осторожно. Т.е., например, если разработчик один и никто больше репозиторий локально не имеет. Или в своей личной ветке, которую никто не использует. Или если сделать это очень быстро, пока другие разработчики, использующие ту же ветку, не обновились (т.е. не имеют локально оргинальных версии исправляемых коммитов). Или таки делать это после общения с коллегами, когда все пришли к выводу, что так лучше всего, и расхождение истории после git pull не станет для них неожиданным сюрпризом.
1. Всё тот же git rebase -i
2. В редакторе у нужного коммита ставите e (edit)
3. Ребейз остановится на этом коммите.
4. Делаете ваши чёрные дела и продолжаете rebase (git rebase --continue).
Всё может быть гораздо проще: по моим наблюдениям, для ряда далёких от IT людей (особенно престарелых) «mail.ru» — это синоним слова «электронная почта».
Т.е. «net@mail.ru» некоторые могут искренне считать, что это значит «нет почты», только по-умному, по-компьютерному.
Это он сам себе противоречит или я чего-то важного не понимаю?
en.bitcoin.it/wiki/Value_overflow_incident
bitcointalk.org/index.php?topic=822.msg9519
А то я чуть было не написал абсолютно такой же комментарий, как и выше :)
То, что я написал в предыдущем комменте в большей части адресовано aikixd с учётом его предыдущих комментов. А вас я просто криво понял. Можно мой предыдущий коммент смело игнорировать. Ваши уточнения по делу.
Это как раз таки штатная ситуация и фактически базовое требование для робота-автомобиля. Если он не сможет этого делать, то он не нужен как таковой вообще. Ну и к тому же, это не чисто программный, а программнно-аппаратный комплекс, т.е. пользуясь вашим примером, если процессор ловит помехи в штатном режиме, очевидно нам надо что-то менять в аппаратной части. А может и в программной.
Ну вот, я пытаюсь всё свести к реальности, а вы пытаетесь решать сугубо теоретическую проблему, которая, как мне кажется, на практике не возникнет :)
Не бывает идеальных сенсоров. Даже те, что имеются на голове у людей, имеют массу багов. Но даже если и предположить, что у нас есть такие сенсоры, это никак не отменяет другого аспекта, о чём я писал выше: алгоритмы разбора нештатных ситуаций если и возможно как-то формализовать, то это чертовски сложная задача. На практике, решение этой задачи превратится в странное непрогнозируемое устройство не имеющее практической цености.
Поясню на примере: у нас есть задача OCR, которая, как правило, решается с использованием нейронных сетей. Казалось бы, обучай нейронку всем существующим буквам всех существующих алфавитов и будет счастье, но, увы, нет: по факту у нас получится огромадная нейронная сеть, которая выдаёт ответы чуть ли не от балды, построив внутренние связи по каким-то совершенно диким критериям. Она начнёт путать иврит с клингонским, грузинкий с тайским и т.п. И кому она нужна? Генератор псевдослучайных чисел можно написать и с меньшими усилиями. :)
К слову, нейронные сети в критически важных продуктах не применяются: для серьёзных вещей требуются хоть какие-то гарантии, формальная верификация и т.п., чего нейронки предоставить не могут.
Подобная ситуация и с экспертной системой для автомобиля: обучив её на тысячах разных ситуаций мы получим что-то странное и ведущее себя непонятным образом. Как я уже говорил в предыдущем комменте, выпускать такое на дороги никто не решится.
Хотя, если продолжать упорствовать с этой идеей, то только тогда может возникнуть проблема, описанная в статье: нашу экспертную систему нужно обучать, что в такой-то ситуации мы давим котика, в такой-то ситуации можно выехать на тротуар, в такой-то — проскочить на красный и т.п.
Но, подытожив, необходимость в подобных размышлениях возникнет, если выполняются следующие условия:
* у нас есть идеальные датчики, которые не шумят, не ломаются и всегда всё прекрасно видят.
* у нас есть идеальная система распознавания сигнала с датчиков, которая всегда верно трактует полученные данные, легко отличает живого человека от рисунка на билборде, отличает упавший башенный кран от пролетающего мимо воздушного шарика и т.п.
* у нас есть идеальная экспертная система, которая в состоянии чётко различать огромное количество похожих ситуаций и принимать верное (или запрограммированное) решение.
Я думаю, что в данном случае есть слишном много «если», чтобы считать проблему, обсуждаемую в данном топике, хоть сколько нибудь близкой к реальности.
Да. Но в этом нет вины ни робота, ни авторов логики робота. Это так сказать, «обстоятельства непреодолимой силы», как, например, попадание метеорита в автомобиль.
Единственно верное решение в любой нештатной ситуации — торможение и ожидание инструкций от оператора-человека. Если оператор не выжил, ну что ж, не судьба :(
Но зато автомобиль гарантированно не выедет на тротуар из-за того, что в дальномер впилился майский жук, не проедет по заполненной людьми остановке автобуса из-за грязи на камере, не выедет на встречку из-за бага в замудрёной логике прошивки.
Сложные ситуации как с башенным краном весьма редки, анализ подобных ситуаций сложен и для человека. А создание робота в логику которого будут забиты тысячи и тысячи подобных нештатных ситуаций выльется в создание мега-глючного монстра, поведение которого никто не сможет предсказать.
Помимо этого есть ещё нюанс с достоверностью получаемых с сенсоров данных. Они никогда не достоверны на 100%. И никогда не будут. Логика предлагаемого вами поведения в случае с башенным краном означает, что на основании того, что роботу показалось, что есть внезапное препятсвие на дороге, он решил съехать на обочину, которая вроде как не остановка общественного транспорта и там кажется нет людей.
Никто не возьмёт на себя ответственность за разрешение такому агрегату перемещаться по дорогам общего назначения. Комиссии будущего просто напросто не сертифицируют робота, который может по каким-то непонятным, труднообъяснимым и сложно формализуемым причинам забить на ПДД.
Не совсем точно: уже самые первые их часики (которые просто Pebble) имели вполне стандартное крепление для ремешка.