У нас все логи которые получаются при прогоне автотестов по системе, хранятся в базе, которая с помощью эвристик находит повторяющиеся ошибки, и заводит баг, и можно посмотреть те логи в которых ошибка была обнаружена, и кроме этого все тэги которые предположительно связаны с появлением этой проблемы.
Но действительно стоящие внимания проблемы через эту систему приходят крайне редко. Обычно выясняется что или тест не был адаптирован после изменения интерфейсов, либо система была неверно сконфигурирована или собрана или прошивка была старая. И редко-редко бывает действительно проблема в коде.
А ошибки находит четырехступенчатый контроль качества, тестировщики в команде разработки, тестировщики на стороне заказчика тестирующие сборку на стендах, отдел контроля качества концерна который делает системные тесты через HIL, и приемочные тесты всей системы в тестировочной фабричной сборке.
Старались не зря.
Вообще мне сама идея микроизменений очень нравится. С удовольствием почитал бы статью на эту тему. Как пользу планировать, нарезать мелкими-мелкими кусочками, аккуратненько вставлять в продукт мелкими порциями, чтобы не вызвать повальной паники и писать красивый чейндж-лог (такой который не стыдно конечному пользователю показать, а не как коммит-коментарии в svn, эхэм-м-м..)
Особенно про чейндж лог интересно, как его писать в так чтобы его читали с открытым ртом. Близзы например тоже так красиво пишут. Сразу всю пользу для конечного пользователя видно. Или на недельном собрании рассказать о проделаной работе, так чтобы все тебя считали «героем галактики», хоть ты и делаешь все тоже самое, что и остальные — фиксишь баги, пишешь фичи.
кстати да, по пятому пункту, у меня схожая история, на фирму я шел тестировщиком, а попал на проект по автоматизации. Когда его передали другой фирме, наши ребята забрали меня в команду разработчиков, как начинающего разработчика, но необходимость писать ui тесты (на нашей embedded- системе занятие довольно муторное) опять сделала меня автоматизатором. Потом я просто прямым текстом отказался становиться разработчиком, а пожелал остаться тестировщиком. Чтобы не требовали сертификаты по яве сдавать и прочую муть. Живу отлично, пишу автоматизацию на весь цех, помогаю молодым-разработчикам. Разработчиком становиться не собираюсь. Хорошим все равно не стану, а плохим лучше не надо. Насмотрелся.
Да и на фирму я устроился тоже так, послал наобум резюме на тестировщика, и когда не ответили пошел спросить почему, и узнать что нужно чтобы быть тестировщиком. Через два дня позвонили, позвали на интервью и взяли на испытательный (решила проявленная инициатива, как мне потом рассказывал кадровик) Но, будем честными до конца, и ситуация решила, человечка им надо было подменить, который два проекта по-полставки делал.
в таком случае как вы относитеть к Siri и wolframalpha.com? тоже не нужно? по вашей логике ведь есть энциклопедии и справочники, и закладки на нужные сайты.
Я добавлю от себя, чем хорош хорошо сделаный бот — он дает информацию в удобном для вас виде. Например мне чтобы проложить маршрут на общ. транспорте по городу, придется минут пятнадцать возиться с сайтом подгадывая время и выписывая нужные данные. А бот он не просто дает сухую справочную информацию а совмещает ее и оборачивает ее в контекст, и например может ответить «если выйдешь сейчас и сядешь на единицу — будешь на работе без пятнадцати двенадцать» и когда я выйду из единицы, он мне скажет куда пересаживаться и что делать. Не бегать с бумажкой и квадратными глазами, а получать нужную информацию в нужное время. Просто цифровой секретарь. Все прогрессивные технологии в начале высмеивали из-за кажущейся избыточности а потом жить без них не могут. Так что ребята двигаются в правильном направлении, я не сомневаюсь. Когда на рынке появится первый конструктор для корпоративных электронных секретарей мы вспомним этот пост.
фарм редких предметов я думаю… Хотя аукцион убрали, но и без него… неужели бегать по стотыщпятисотому разу по одним и тем же локациям раскидывая монстров направо и налево?
«Как дешевле всего пересчитать все песчинки на пляже?». Никак. Если расходам не противопоставлен больший доход, то это убыточное дело. Независимо от того насколько малы расходы. А про средний доход от одной статьи ничего не было сказано.
Дональд Кнут напоминает: «Преждевременная оптимизация — корень всех зол»
Это вряд ли будет объективно. Пока носители языка считают его удобным, количество критики в адрес этого языка будет просто выражением углового коэффициента кривой обучения для изучающих его.
Я неудачно выразился. Не очень не в том смысле. А в смысле опыта. Хорошо владеющие языком и не очень. Т.е. когда ты в совершенстве владеешь языком, он не кажется тебе странным. Трудности возникают при переходе, особенно при смене парадигмы.
Когда я только начал учить английский язык мне не нравилось что там есть определенный и неопределенный артикль который, не до конца понятно зачем нужен. Потом я по воле судьбы выучил немецкий язык который тоже имеет определенный и неопределенный артикль. Но немецким, по прошествии шестнацати лет, я владею как вторым родным языком и мне артикль кажется уже не искуственной вещью (надо ставить, будем ставить), а естественной. И в английском языке, поскольку они родственные, артикль стал для меня такой же естественной вещью.
Наверно правильно не язык ругать, а то что его трудно учить. Наверно это будет более объективной критикой.
Язык программирования это ведь в первую очередь всего лишь язык. Странно было бы если бы все взахлеб восхищались испанским или до хрипа хейтили корейский. А вот среди переводчиков есть хорошие и не очень. Мне кажется дело только в этом.
у меня молодые коллеги, они регулярно пялятся в телефон. Я же не могу отвлечься от мыслей, моя голова постоянно занята какой то задачей, и мне не до фейсбуков. Мне жалко времени на работе чтобы просиживать его бесцельно. Могу конечно глянуть амазон выслали посылку или нет, но это касается планирования дальнейших действий.
Мой тим лид вообые удивительный человек, он может весь день работать не вставая, писать код в то время как отвечает на твой вопрос, отвечать на твой вопрос пока слушает аудиоконференцию. его спрашивали как он может слушать два источника одновременно, он говорит что а аудиоконференции ему нужно слышать только ключевые слова. И действительно он говорит с тобой, включает микрофон, комментирует в конференцию, отключает микрофон и продолжает разговор с тобой с того места где вы остановились. Я не знаю как такое возможно. Вот что я заметил, каким правилом эффективности он пользуется в силу своей натуры, если к нему приходят с вопросом, он обрабатывает это сразу, пока ты задаешь вопрос он уже листает документацию, код или что нужно, и ты еще не успел сформулировать мысль до конца уже получаешь ответ.
В общении все его высказывания сведены к такому минимуму который достаточен для однозначного понимания. Никаких ненужных для выполнения задачи подробностей.
Сам я частенько забываю поздороваться, по той же причине, голова занята мыслями о какой-то задаче. На работу я прихожу уже зная что сделаю сначала. Многие коллеги просто выполняют рутинные заученные дейтвия не спрашивая себя а нужно ли это сейчас, например обновление артефактов. Опытные разработчики могут артефакты неделями не обовлять, зная что их код от них не зависит.
Людей которые не склонны ценить свое время не научишь этому, я кажется. Мне вот просто жалко тратить рабочее время на фигню. Время на работе это для меня возможность пользоваться ресурсами которые доступны только на рабочем месте. Которых нет дома.
Мне вот больше интересно, кто как реагирует когда у него «затык»? Мне например нужно встать и куда-то пойти. Сидя на пятой точке я не могу «продавить» проблему, или найти к ней новый подход. Начинаю кипеть.
Всегда представлял себе администрацию хабра весьма суровой. А тут такое. Сразу на сердце потеплело. Ваша карма на моем балансе переползла из синего сектора в зеленый :)
Наткнулся как-то на вот такую концепцию. https://www.minnosphere.com/mydata
Это решение — мобильная система управления личными данными. Kонцепция кажется вполне прозрачной. Принцип действия схож с тем как мы разрешаем или запрещаем доступ сторонних приложений к данным на фейсбуке и пр. Как я понимаю «трудность» распространения такого решения в том, что генераторы данных будут вынуждены поддерживать интерфейс платформы управления личными данными. И в теории могут возникнуть сотни таких платформ, и проблема просто перейдет в новое измерение. Кроме того напрашивается вопрос чей рычаг давления длинее, конечного клиента или производителей продуктов использующих личные данные. Сможет ли конечный пользователь вынудить производителей поддерживать такие платформы. С другой стороны это как бы и в интересах производителей, ведь доверие клиентов вещь давно уже не шуточная.
Но действительно стоящие внимания проблемы через эту систему приходят крайне редко. Обычно выясняется что или тест не был адаптирован после изменения интерфейсов, либо система была неверно сконфигурирована или собрана или прошивка была старая. И редко-редко бывает действительно проблема в коде.
А ошибки находит четырехступенчатый контроль качества, тестировщики в команде разработки, тестировщики на стороне заказчика тестирующие сборку на стендах, отдел контроля качества концерна который делает системные тесты через HIL, и приемочные тесты всей системы в тестировочной фабричной сборке.
Вообще мне сама идея микроизменений очень нравится. С удовольствием почитал бы статью на эту тему. Как пользу планировать, нарезать мелкими-мелкими кусочками, аккуратненько вставлять в продукт мелкими порциями, чтобы не вызвать повальной паники и писать красивый чейндж-лог (такой который не стыдно конечному пользователю показать, а не как коммит-коментарии в svn, эхэм-м-м..)
Особенно про чейндж лог интересно, как его писать в так чтобы его читали с открытым ртом. Близзы например тоже так красиво пишут. Сразу всю пользу для конечного пользователя видно. Или на недельном собрании рассказать о проделаной работе, так чтобы все тебя считали «героем галактики», хоть ты и делаешь все тоже самое, что и остальные — фиксишь баги, пишешь фичи.
Да и на фирму я устроился тоже так, послал наобум резюме на тестировщика, и когда не ответили пошел спросить почему, и узнать что нужно чтобы быть тестировщиком. Через два дня позвонили, позвали на интервью и взяли на испытательный (решила проявленная инициатива, как мне потом рассказывал кадровик) Но, будем честными до конца, и ситуация решила, человечка им надо было подменить, который два проекта по-полставки делал.
Я добавлю от себя, чем хорош хорошо сделаный бот — он дает информацию в удобном для вас виде. Например мне чтобы проложить маршрут на общ. транспорте по городу, придется минут пятнадцать возиться с сайтом подгадывая время и выписывая нужные данные. А бот он не просто дает сухую справочную информацию а совмещает ее и оборачивает ее в контекст, и например может ответить «если выйдешь сейчас и сядешь на единицу — будешь на работе без пятнадцати двенадцать» и когда я выйду из единицы, он мне скажет куда пересаживаться и что делать. Не бегать с бумажкой и квадратными глазами, а получать нужную информацию в нужное время. Просто цифровой секретарь. Все прогрессивные технологии в начале высмеивали из-за кажущейся избыточности а потом жить без них не могут. Так что ребята двигаются в правильном направлении, я не сомневаюсь. Когда на рынке появится первый конструктор для корпоративных электронных секретарей мы вспомним этот пост.
Дональд Кнут напоминает: «Преждевременная оптимизация — корень всех зол»
Когда я только начал учить английский язык мне не нравилось что там есть определенный и неопределенный артикль который, не до конца понятно зачем нужен. Потом я по воле судьбы выучил немецкий язык который тоже имеет определенный и неопределенный артикль. Но немецким, по прошествии шестнацати лет, я владею как вторым родным языком и мне артикль кажется уже не искуственной вещью (надо ставить, будем ставить), а естественной. И в английском языке, поскольку они родственные, артикль стал для меня такой же естественной вещью.
Наверно правильно не язык ругать, а то что его трудно учить. Наверно это будет более объективной критикой.
Мой тим лид вообые удивительный человек, он может весь день работать не вставая, писать код в то время как отвечает на твой вопрос, отвечать на твой вопрос пока слушает аудиоконференцию. его спрашивали как он может слушать два источника одновременно, он говорит что а аудиоконференции ему нужно слышать только ключевые слова. И действительно он говорит с тобой, включает микрофон, комментирует в конференцию, отключает микрофон и продолжает разговор с тобой с того места где вы остановились. Я не знаю как такое возможно. Вот что я заметил, каким правилом эффективности он пользуется в силу своей натуры, если к нему приходят с вопросом, он обрабатывает это сразу, пока ты задаешь вопрос он уже листает документацию, код или что нужно, и ты еще не успел сформулировать мысль до конца уже получаешь ответ.
В общении все его высказывания сведены к такому минимуму который достаточен для однозначного понимания. Никаких ненужных для выполнения задачи подробностей.
Сам я частенько забываю поздороваться, по той же причине, голова занята мыслями о какой-то задаче. На работу я прихожу уже зная что сделаю сначала. Многие коллеги просто выполняют рутинные заученные дейтвия не спрашивая себя а нужно ли это сейчас, например обновление артефактов. Опытные разработчики могут артефакты неделями не обовлять, зная что их код от них не зависит.
Людей которые не склонны ценить свое время не научишь этому, я кажется. Мне вот просто жалко тратить рабочее время на фигню. Время на работе это для меня возможность пользоваться ресурсами которые доступны только на рабочем месте. Которых нет дома.
Это решение — мобильная система управления личными данными. Kонцепция кажется вполне прозрачной. Принцип действия схож с тем как мы разрешаем или запрещаем доступ сторонних приложений к данным на фейсбуке и пр. Как я понимаю «трудность» распространения такого решения в том, что генераторы данных будут вынуждены поддерживать интерфейс платформы управления личными данными. И в теории могут возникнуть сотни таких платформ, и проблема просто перейдет в новое измерение. Кроме того напрашивается вопрос чей рычаг давления длинее, конечного клиента или производителей продуктов использующих личные данные. Сможет ли конечный пользователь вынудить производителей поддерживать такие платформы. С другой стороны это как бы и в интересах производителей, ведь доверие клиентов вещь давно уже не шуточная.