Ну тут связь скорее не услышать космонавтов — я так понимаю, в это время их и так нихило пригибает перегрузкой. Телеметрия, может какое-то пассивное управление аппаратом, смещение, поворот.
Да, конечно, тут я неправильно выразился. Для этого у них есть отдельный тип Usability Problem. Что обычно приравнивается по важности к багам или около того.
помеченные дубликаты не могли попасть по этим состояниям.
Конечно не могли, есть state=Duplicate и то, что он является Resolved по сути, это уже второстепенно, а то что он уже не Open, Submitted, In Progress — определяет попадёт он в выборку или нет. Если по стейтам не фильтровать, а просто брать по типу, то тогда попадают. В общем-то в основном этим и объясняются некоторые пики зарепорчено/зарезолвено. Было пару больших проблем в истории с кучей дубликатов.
Тут я с Вами согласен, но абсолютно с точки зрения наоборот: когда я пользовался EAP года 4 назад, это была именно EAP и для работы не годилась, падало, брыкалось, что только ни делало, лишь бы не работать. Сейчас же я сижу исключительно на EAP сборках и они очень редко валятся с критическими ошибками.
Касательно статьи в целом — плюс за поднятие темы, но минус за рассмотрение проблемы с эмоциональной точки зрения "вы меня задолбали, я ухожу, вот вам гневное письмо". Как активный репОртер, я знаю, что есть баги, которые не являются критическими (low priority) или воспроизводимыми (вроде и важный, но проявляется при куче совпадений у одного человека. Все об этом вроде знают, но сделать ничего не могут). Так же есть баги, которые уже давно устарели (здесь проблема разбора ютрака, а не фикса багов, также проблема того что репортеры зачастую не комментят баг как "May be closed as obsolete/unreproducible" и такие баги (хотя по факту уже давно ими не являющиеся) висят годами и никому не мешают, приорити не растёт, в списке вверх не поднимается).
Так же, как выше заметили, кол-во пользователей растёт, кол-во репортов растёт. И это не значит что багов стало больше, часть из них старые, но ранее не зарепорченные. Плюс к этому зоопарк плагинов, поддержка новых фреймворков в ядре как плюс к увеличению разных комбинаций для выявления бага в уже (может быть, лет как 6 назад) написанном коде.
Но да, частично (очень незначительно) я с вами и согласен, поскольку есть баги, которые мешают жить, но, почему-то, только вам. Например я пользуюсь сплит-видом без тулбаров и табов, и не всегда точно помню, который файл открыт рядом. Уже давно прошу просто показывать имя файла в углу, как, например, https://jsfiddle.net/ делает. Но я отчётливо понимаю, что так IDE пользуется крайне мало людей, и ещё меньше из них способны и имеют желание зайти на ютрак и оставить схожую просьбу/поставить +1 моей просьбе. Оно так и висит 2.5 года.
Я так понимаю, что практические единственный способ что-то исправить/улучшить если запрос крайне непопулярный — это PR в open source CE. Ещё можно на форуме у них поспрошать, может через разбор бага (или её важность) до разработчиков не дошла.
UPD: Ну конечно же ещё есть такой фактор как правильно оформленные баги. "У меня тут что-то не работает" фиксится крайне редко.
А у аудитории хотелось бы поинтересоваться — ставил ли кто выдвигающийся экран из 1 din? Какие, как работают, насколько хлипкие? Не хочется корёжить панель.
В принципе, наложений с другими сигналами не испытываю, там настраивается частота, так что можно выбрать неиспользуемую. Конечно, до поры до времени, никаких гарантий нет что частота будет свободна.
Данный трансмиттер если не подключён к телефону ничего распевать не будет, так что и сажать аккум не должен.
Неудобство управления — это да, но громче/тише/mute работает и с магнитолы.
тыкаясь в слепую в маленькую коробочку
Btw, это вы про трансмиттер или про телефон? Трансмиттер не имеет никаких контролов, всё управление через медиа-проигрыватель на телефоне. Свайп сверху вниз (например активно приложение навигатора) -> там три кнопки — предыдущий трек, play/stop, следующий трек. Не очень удобно, но в принципе, юзабельно. На радио тоже не особенно треки попереключаешь :) Так что как альтернатива радиостанциям вполне годно.
Я вот тоже думал в машину влепить и большой экран с камерой заднего вида, но всё это было в основе своей из-за музыки. Музыка решилась девайсом "Xiaomi Roidmi 2S" который просто транслирует музыку с телефона на заданной частоте радио — теперь просто переключается нужная станция и музыка играет из колонок.
Необходимость в танцах с бубном/ aux/ usb отпала (а так хотелось).
Ну инструкции по эксплуатации тоже как правило достаточно просты. Например, инструкции стиральных машин помещаются на одном листке A5 в картинках.
Всякие "запрещено сушить кошек" и "не засовывать палочки глубоко в ухо" это скорее отказ от ответственности, чем инструкция по эксплуатации, который (отказ) и должен быть описан юридическим языком для возможного рассмотрения в суде. Инструкция — это другое.
Ну здесь, всё-таки, самый простой выход — это вывод в консоль. Последнее выведенное значение будет перед исключением — а там и до правила в брекпоинте недалеко. Как бы нет особого смысла сидеть и клацать 319 раз. Может я слишком ленивый для этого?
Если падает из-за каких-то параметров — это должно быть просто при выводе. Если может упасть из-за внешних факторов, которые так просто не выведешь в консоль — ну тут и дебаггер не всегда поможет, а иногда даже помешает, поскольку нарушит обычное течение программы зависаниями на брекпоинтах.
Кто знает грамматику!
Пробовал довольно длительное время.
Не помогло. Когда альтернативной рекламы больше нет, показывается вся подряд вне зависимости от фидбека
Ну тут связь скорее не услышать космонавтов — я так понимаю, в это время их и так нихило пригибает перегрузкой. Телеметрия, может какое-то пассивное управление аппаратом, смещение, поворот.
Да, конечно, тут я неправильно выразился. Для этого у них есть отдельный тип
Usability Problem. Что обычно приравнивается по важности к багам или около того.Конечно не могли, есть
state=Duplicateи то, что он являетсяResolvedпо сути, это уже второстепенно, а то что он уже неOpen, Submitted, In Progress— определяет попадёт он в выборку или нет. Если по стейтам не фильтровать, а просто брать по типу, то тогда попадают. В общем-то в основном этим и объясняются некоторые пики зарепорчено/зарезолвено. Было пару больших проблем в истории с кучей дубликатов.Примерно равно "не кажется ли странным заплатить за продукт и потом репортить баги? Это же работа тестировщиков, им за это платят".
Нет, не кажется.
А ещё это похоже на 50+ вкладок в Хроме "потом посмотрю" и "а почему у меня Хром тормозит?".
Вроде как по стейту только брались
Open, Submitted, In Progress.Тут я с Вами согласен, но абсолютно с точки зрения наоборот: когда я пользовался EAP года 4 назад, это была именно EAP и для работы не годилась, падало, брыкалось, что только ни делало, лишь бы не работать. Сейчас же я сижу исключительно на EAP сборках и они очень редко валятся с критическими ошибками.
Касательно статьи в целом — плюс за поднятие темы, но минус за рассмотрение проблемы с эмоциональной точки зрения "вы меня задолбали, я ухожу, вот вам гневное письмо". Как активный репОртер, я знаю, что есть баги, которые не являются критическими (low priority) или воспроизводимыми (вроде и важный, но проявляется при куче совпадений у одного человека. Все об этом вроде знают, но сделать ничего не могут). Так же есть баги, которые уже давно устарели (здесь проблема разбора ютрака, а не фикса багов, также проблема того что репортеры зачастую не комментят баг как "May be closed as obsolete/unreproducible" и такие баги (хотя по факту уже давно ими не являющиеся) висят годами и никому не мешают, приорити не растёт, в списке вверх не поднимается).
Так же, как выше заметили, кол-во пользователей растёт, кол-во репортов растёт. И это не значит что багов стало больше, часть из них старые, но ранее не зарепорченные. Плюс к этому зоопарк плагинов, поддержка новых фреймворков в ядре как плюс к увеличению разных комбинаций для выявления бага в уже (может быть, лет как 6 назад) написанном коде.
Но да, частично (очень незначительно) я с вами и согласен, поскольку есть баги, которые мешают жить, но, почему-то, только вам. Например я пользуюсь сплит-видом без тулбаров и табов, и не всегда точно помню, который файл открыт рядом. Уже давно прошу просто показывать имя файла в углу, как, например, https://jsfiddle.net/ делает. Но я отчётливо понимаю, что так IDE пользуется крайне мало людей, и ещё меньше из них способны и имеют желание зайти на ютрак и оставить схожую просьбу/поставить +1 моей просьбе. Оно так и висит 2.5 года.
Я так понимаю, что практические единственный способ что-то исправить/улучшить если запрос крайне непопулярный — это PR в open source CE. Ещё можно на форуме у них поспрошать, может через разбор бага (или её важность) до разработчиков не дошла.
UPD: Ну конечно же ещё есть такой фактор как правильно оформленные баги. "У меня тут что-то не работает" фиксится крайне редко.
Ну по большому счёту, корпус-то вообще не обязателен.
Хотелось бы продолжения истории.
А у аудитории хотелось бы поинтересоваться — ставил ли кто выдвигающийся экран из 1 din? Какие, как работают, насколько хлипкие? Не хочется корёжить панель.
Изначально засматривался на вот это схему: https://geektimes.ru/post/272210/
В принципе, наложений с другими сигналами не испытываю, там настраивается частота, так что можно выбрать неиспользуемую. Конечно, до поры до времени, никаких гарантий нет что частота будет свободна.
Данный трансмиттер если не подключён к телефону ничего распевать не будет, так что и сажать аккум не должен.
Неудобство управления — это да, но громче/тише/mute работает и с магнитолы.
Я вот тоже думал в машину влепить и большой экран с камерой заднего вида, но всё это было в основе своей из-за музыки. Музыка решилась девайсом "Xiaomi Roidmi 2S" который просто транслирует музыку с телефона на заданной частоте радио — теперь просто переключается нужная станция и музыка играет из колонок.
Необходимость в танцах с бубном/ aux/ usb отпала (а так хотелось).
Ну инструкции по эксплуатации тоже как правило достаточно просты. Например, инструкции стиральных машин помещаются на одном листке A5 в картинках.
Всякие "запрещено сушить кошек" и "не засовывать палочки глубоко в ухо" это скорее отказ от ответственности, чем инструкция по эксплуатации, который (отказ) и должен быть описан юридическим языком для возможного рассмотрения в суде. Инструкция — это другое.
Ну это смотря какие инструкции смотреть. Вы читали (смотрели? Там вроде букв почти нет) инструкции по сборке от IKEA?
Может быть, для юристов желающих прикопаться к каждому слову в "свободной трактовке" следует добавить внизу ссылку "официальная версия письма здесь".
А как исходники относятся к коду на недоступном для вас сервере? Правильно, по честному слову.
А ещё можно временно обернуть в try-catch и поставить брекпоинт в кетче.
Ну здесь, всё-таки, самый простой выход — это вывод в консоль. Последнее выведенное значение будет перед исключением — а там и до правила в брекпоинте недалеко. Как бы нет особого смысла сидеть и клацать 319 раз. Может я слишком ленивый для этого?
Если падает из-за каких-то параметров — это должно быть просто при выводе. Если может упасть из-за внешних факторов, которые так просто не выведешь в консоль — ну тут и дебаггер не всегда поможет, а иногда даже помешает, поскольку нарушит обычное течение программы зависаниями на брекпоинтах.