Я хотел написать «эксепшене»
В общем-то, мне про эту опечатку сказали несколько часов назад. Но я её предпочёл уже не править — времени после написания прошло много, и это слегка некорректно — править давно написанный текст без явных оповещений о том.
Что такой стэк трейс при ожиданиях — мне не совсем понятно, а оттого и суть двусмысленности мне не ясна.
Что же до англицизмом… что ж, меня тоже бомбит, когда англицизмы используют для имеющихся в русском языке понятий, вводя тем самым новые термины взамен русских устоявшихся.
Но в такой области языка, как разработка ПО…
> Последовательность вызов / ошибки в инструментах браузера при явном возникновении исключительной ситуации
Серьёзно? Стало понятнее? )
— Дальше довольно много претензий про то, что тестировщик должен и не должен.
Тут дело в том, что я не тестировщик, и писал не для тестировщиков. Я писал для разработчиков ПО, техрайтеров… для всех своих коллег.
Конечно, некоторые из них могут стать в определённый момент работы тестировщиками, и это будет хорошо.
— >Просто пиши то что ты видишь, а не то что ты думаешь
Это хорошее дополнение, спасибо за него.
Это противопоставление неверно. Как мне недавно подсказали, оно называется теоремой Эскобара. Ссылку давать не буду, потому что она сформулирована в обсценённой лексике, но она хорошо гуглится )
Вы подменяете тезис о том, что баг должен быть записан хорошо, тезисом о том, что баг должен быть записан только с шагами и никак иначе.
В описанной ситуации, когда баг пришёл с продакшена от нормальных людей, я бы спрашивал базу данных (то есть пример для воспроизведения).
И логи должны быть, да. Обычно после таких невоспроизводимых багов и добавляются на продакшене новые логи.
Я правильно понял по видео, что у них, грубо говоря, инлайн-редактирование скриншота прямо как будто бы до его снятия?
Выглядит и вправду забавно, доберусь дома до убунту — попробую.
А вот тут тоже вопрос дискуссионный
Мастер-тикеты уже начинают искажать статистику по количеству багов )
Да и вообще… так ли они нужны?
Нам последнее время, если встречаются связанные баги — что в общем-то происходит таки достаточно редко — хватает линкования peer-to-peer
В каждом из них в комментах проставляем ссылки.
Низкоорганизовано, ненормализованно… но в большинстве случаев — достаточно.
:) да, это пофикшено в версиях 19.1.4 и 18.2.9, как я только что убедился, проверив свой тикет.
Который, кстати, имеет ещё одну проблему, о которой я совсем забыл сказать. Я в одном багрепорте записал три разные проблемы (хоть все они и были связаны).
Забавная штука.
Полноценную скриншотилку не заменит (нет стрелочек из коробки, нарисованное не является векторным — его править тяжело, нет текста)
Но на голой чужой машине — может быть очень даже ничего, спасибо
>Очень часто для починки бага достаточно одного только стектрейса.
Ну, это только в первые пять лет жизни продукта!.. :-D
Сарказм, но всё же: очевидные ошибки, которые воспроизводятся быстро, потому что они в основном функционале, ловятся быстро, в первые дни/недели после релиза нового функционала; и там, действительно, стектрейса хватает.
Но потом, когда функционал начинает жить своей жизнью, и пользователи нагибают его так, как автору и не снилось… вот там уже без шагов зачастую не разберёшься.
Если бы все программы были stateless — было бы проще, но увы :(
Я их тоже голосовые сообщения терпеть не могу… но, кажется, нам придётся с ними жить
Я как раз на днях смотрел доклад c новосибирского КодФеста парня из ВКонтактика, ответственного за мессенджер. Он рассказывает, что голосовые сообщения в мессенджерах сейчас начинают побеждать текстовые.
Вот тут смотрел: www.youtube.com/watch?v=2LaP4pqTqGU
Ну, да, бывали случаи, когда видео оказывалось прям полезно-полезно-полезно. То есть если бы не оно, то и фикса могло бы не быть, потому что проблема оказалось бы не понятной в принципе.
Но это всё же от бедности )
Ну и для себя вывел, что если вот так благодаря видео пришло таки озарение — то надо его хотя бы самому в комментах к багу записать. Чтобы все будущие читатели были благодарны.
Нам приходят баги не только внутренние, но и от наших кастомеров. И вот там мы взяли себе за правило дополнять баг необходимой технической информацией в приватных комментарих.
Спасибо!
Строго говоря, тестировщиком я никогда не был, я был программистом ) Потом был тимлидом, доносящим обшибки до своей команды ) и прочувствовал в общем-то с обеих сторон, да.
Если в момент взятия интервью интервьюер не бухал с интервьюируемым, то использование термина «нахер» в вопросах выглядит странно.
Я бы после этого на вопросы уже отвечать не стал :)
Если бухали — то вопросов нет, это нормально в дружеском общении. Но тогда это в статье стоило бы уточнить.
Мы — не можем так сделать, потому что мы не пишем приложение
Мы пишем контрол, который люди вставляют в свои приложения
А в нашем девелоперском приложении, где мы разрабатываемся — мы так и делаем, понятное дело. Да и в нашем ASP.NET WebForms контроле тоже врендериваем в рантайме как часть страницы.
Вот только это очень хороший пункт:
display: none
делать нельзя. В некоторых браузерах в некоторых случаях (честное слово, не помню деталей — то ли ИЕ, то ли FF) — это губит работу с иконками.
Поэтому див должен быть display: block, visibility: hidden, position: absolute, left: -10px, top: -10px, width: 1px, height: 1px
Так у него работают градиенты и не растаращивает файрфокс огромный скроллбаром на этом невидимом элементе.
Все иконки, что вы видите на это скриншоте, добавлены на страницу при помощи описанной технологии.
Иконки готовятся в Adobe Illustrator; средствами самого иллюстратора создаются «стили», которые при экспорте в SVG становятся настоящими CSS-стилями, которые мы перебиваем своими правилами. Дизайнер делает всё своими инструментами, помощь программиста для создания иконок не нужна. То есть всё на удивление нативно вышло с дизайнерскими средствами.
Вот так мы прям в начале CSS отбиваем эти стили у иконок на уровне темплейта:
//меняет сам шаблон
.dx_blue {
fill: #579ADD;
}
// вот это, кстати, перекрашивается в тёмной теме - отдельной CSS
// без использования описанной технологии, но оч. удобно
.dx_darkgray {
fill: #414141;
}
symbol#dx-dashboard-binding-panel-pie {
.dx_blue {
fill: inherit;
}
}
И с этого момента можем использовать описанную технику с use для изменения цвета элемента иконки.
Какие ещё тонкие моменты:
— IE зачастую оооочень странно прокидыет ивенты мыши из таких теневых элементов.
Поэтому почти везде на самих иконках мы ставим pointer-events: none, и обрабатываем ивенты на уровень выше;
— IE зачастую не перерисовывает иконки, если играться с display свойствами их родителей. Поскольку у нас много иконок лежит на оверлеях — мы с этим прилично наборолись. Приходилось заниматься мистическими перестановками в ДОМе, надеясь, что очередной способ IE поймёт правильно
В последних версиях они это как будто бы починили.
И в общем-то, у нас всё хорошо. Разве что каждого нового программиста приходится отправлять читать эту статью :)
В общем-то, мне про эту опечатку сказали несколько часов назад. Но я её предпочёл уже не править — времени после написания прошло много, и это слегка некорректно — править давно написанный текст без явных оповещений о том.
Что такой стэк трейс при ожиданиях — мне не совсем понятно, а оттого и суть двусмысленности мне не ясна.
Что же до англицизмом… что ж, меня тоже бомбит, когда англицизмы используют для имеющихся в русском языке понятий, вводя тем самым новые термины взамен русских устоявшихся.
Но в такой области языка, как разработка ПО…
> Последовательность вызов / ошибки в инструментах браузера при явном возникновении исключительной ситуации
Серьёзно? Стало понятнее? )
— Дальше довольно много претензий про то, что тестировщик должен и не должен.
Тут дело в том, что я не тестировщик, и писал не для тестировщиков. Я писал для разработчиков ПО, техрайтеров… для всех своих коллег.
Конечно, некоторые из них могут стать в определённый момент работы тестировщиками, и это будет хорошо.
— >Просто пиши то что ты видишь, а не то что ты думаешь
Это хорошее дополнение, спасибо за него.
Вы подменяете тезис о том, что баг должен быть записан хорошо, тезисом о том, что баг должен быть записан только с шагами и никак иначе.
В описанной ситуации, когда баг пришёл с продакшена от нормальных людей, я бы спрашивал базу данных (то есть пример для воспроизведения).
И логи должны быть, да. Обычно после таких невоспроизводимых багов и добавляются на продакшене новые логи.
Выглядит и вправду забавно, доберусь дома до убунту — попробую.
Мастер-тикеты уже начинают искажать статистику по количеству багов )
Да и вообще… так ли они нужны?
Нам последнее время, если встречаются связанные баги — что в общем-то происходит таки достаточно редко — хватает линкования peer-to-peer
В каждом из них в комментах проставляем ссылки.
Низкоорганизовано, ненормализованно… но в большинстве случаев — достаточно.
Который, кстати, имеет ещё одну проблему, о которой я совсем забыл сказать. Я в одном багрепорте записал три разные проблемы (хоть все они и были связаны).
По хорошему, одна проблема — один багрепорт.
Полноценную скриншотилку не заменит (нет стрелочек из коробки, нарисованное не является векторным — его править тяжело, нет текста)
Но на голой чужой машине — может быть очень даже ничего, спасибо
Ну, это только в первые пять лет жизни продукта!.. :-D
Сарказм, но всё же: очевидные ошибки, которые воспроизводятся быстро, потому что они в основном функционале, ловятся быстро, в первые дни/недели после релиза нового функционала; и там, действительно, стектрейса хватает.
Но потом, когда функционал начинает жить своей жизнью, и пользователи нагибают его так, как автору и не снилось… вот там уже без шагов зачастую не разберёшься.
Если бы все программы были stateless — было бы проще, но увы :(
Я как раз на днях смотрел доклад c новосибирского КодФеста парня из ВКонтактика, ответственного за мессенджер. Он рассказывает, что голосовые сообщения в мессенджерах сейчас начинают побеждать текстовые.
Вот тут смотрел: www.youtube.com/watch?v=2LaP4pqTqGU
Но это всё же от бедности )
Ну и для себя вывел, что если вот так благодаря видео пришло таки озарение — то надо его хотя бы самому в комментах к багу записать. Чтобы все будущие читатели были благодарны.
Нам приходят баги не только внутренние, но и от наших кастомеров. И вот там мы взяли себе за правило дополнять баг необходимой технической информацией в приватных комментарих.
Строго говоря, тестировщиком я никогда не был, я был программистом ) Потом был тимлидом, доносящим обшибки до своей команды ) и прочувствовал в общем-то с обеих сторон, да.
Пойду баг репортить )
Я бы после этого на вопросы уже отвечать не стал :)
Если бухали — то вопросов нет, это нормально в дружеском общении. Но тогда это в статье стоило бы уточнить.
Дэшбоарды от ДевЭкспресса
www.devexpress.com/Products/NET/Dashboard
С веб-дизайнером, которые мы сотоварищи пилим последнюю пару лет
demos.devexpress.com/Dashboard/?mode=viewer
Сервак обязательно на .NET (можно .NET Core под линухом), клиентская часть — просто js, можно встроить в любой фреймворк.
Если щас мой коммент сочтут не просветительским, а рекламным — прощайте, друзья чачкасы.
Мы пишем контрол, который люди вставляют в свои приложения
А в нашем девелоперском приложении, где мы разрабатываемся — мы так и делаем, понятное дело. Да и в нашем ASP.NET WebForms контроле тоже врендериваем в рантайме как часть страницы.
Вот только это очень хороший пункт:
делать нельзя. В некоторых браузерах в некоторых случаях (честное слово, не помню деталей — то ли ИЕ, то ли FF) — это губит работу с иконками.
Поэтому див должен быть display: block, visibility: hidden, position: absolute, left: -10px, top: -10px, width: 1px, height: 1px
Так у него работают градиенты и не растаращивает файрфокс огромный скроллбаром на этом невидимом элементе.
После такой эмоциональной статьи, слово "полях" прочитал сначала неправильно....
Поскольку тут ещё есть люди и приходят новые, решил дописать о результатах.
Подход полностью летит на нашем рабочем проекте — веб-дизайнере дэшбоардов.
Все иконки, что вы видите на это скриншоте, добавлены на страницу при помощи описанной технологии.
Иконки готовятся в Adobe Illustrator; средствами самого иллюстратора создаются «стили», которые при экспорте в SVG становятся настоящими CSS-стилями, которые мы перебиваем своими правилами. Дизайнер делает всё своими инструментами, помощь программиста для создания иконок не нужна. То есть всё на удивление нативно вышло с дизайнерскими средствами.
Вот такой иконка становится после прогона через билдёжку (в данный момент — Gulp, плагины gulp-svgstore + gulp-svgmin)
Вот так мы прям в начале CSS отбиваем эти стили у иконок на уровне темплейта:
И с этого момента можем использовать описанную технику с use для изменения цвета элемента иконки.
Какие ещё тонкие моменты:
— IE зачастую оооочень странно прокидыет ивенты мыши из таких теневых элементов.
Поэтому почти везде на самих иконках мы ставим pointer-events: none, и обрабатываем ивенты на уровень выше;
— IE зачастую не перерисовывает иконки, если играться с display свойствами их родителей. Поскольку у нас много иконок лежит на оверлеях — мы с этим прилично наборолись. Приходилось заниматься мистическими перестановками в ДОМе, надеясь, что очередной способ IE поймёт правильно
В последних версиях они это как будто бы починили.
И в общем-то, у нас всё хорошо. Разве что каждого нового программиста приходится отправлять читать эту статью :)
Даёшь кокпит!
Хорошее же, русское слово