Увы
Увеличение ширины стола → Увеличение длины помоста → Становится неудобно залезать на лежаночку.

Везде свои ограничения )

Ну… да, бывает, что сверху простора не хватает.
Что поделать — как мог выкручивался, миллиметраж ловил.

В следующий раз — кабинет не менее 25 м² :-D

Ну а пока — за неимением туалетной бумаги воспользуемся наждачной (с).

Сам свалиться не боюсь, хотя пара неприятных эпизодов в состоянии лёгкого алкогольного опьянения на ступеньках случилось…
Вот за детей страшно, это да.

Снизу у меня лежаночка для чтения. Как на печи, только снизу. Но так же тепло (там радиатор за фальшстеной)
Плюс полки с книгами
Плюс шкафчик небольшой

Свой свет с выключателями в нижней зоне, один для чтения лёжа, другой яркий для поиска на полках

Пыль на полках перед книжками собирается, это правда.
Пыль — это вообще беда книжника )

И это правильно.

Да, у меня там как раз трубы, тольк диаметр поменьше — кажется, 15 мм. Экономил толщину стены со спальней, не хотел вгрызаться…
И это оказалось ошибкой, потому что HDMI-штекер через неё закономерно не пролезает, а моя идея — пропускать microHDMI и после выхода из стены использовать переходник microHDMI-HDMI оказалась с подвохом — MicroHDMI, оказывается, не только маленький, но и хлипкий :-D Я уже штук шесть переходников сменил…
Зато с покупкой ноута я перешёл на mini-DisplayPort — и жизнь наладилась, потому что он капитальный, но пролезает, и напрямую в ноут без переходников втыкается.

Короб 50х100 у меня тоже есть, но в гостиной, для кабелей телика )

А себе дома из кладовки построил двухэтажный кабинет. И у меня на столе книжные полки %-) А все провода спрятаны в стену (кроме тех, которые я не предусмотрел :-D)







Извините, просто не смог не похвастаться. Я понимаю, что выглядит чудно :) Но мне правда хорошо тут.
Чуть подробнее в ЖЖ.

>Помимо этого происходит добавление персоны в стоп-лист на ближайшее время, что позволяет избежать многократных уведомлений об одном и том же человеке;

Нет ли тут уязвимости?.. злоумышленник сможет запустить человека-похожего-на-него, чтобы спровоцировать ложное срабатывание; оператор посмотрит на человека, увидит, что это лишь похожий; настоящий злоумышленник входит в камеру — а предупреждения уже нет, потому что он в стоп-листе?..

В общем-то, меня яндекс по запросу «наушники TWS что такое» именно сюда и привёл :)

Ну, может стоит (после релиза) сесть вместе, поработать в паре, показать свои подходы и почему они лучшее, удобнее и быстрее для всех?..

Статистика — ну, чтобы понять — вот тут мы работали полгода, и после этого накопилось просроченных багов
А вот тут мы полгода работали по-другому, и тогда завала багов не было
То есть это больше для последующего анализа, а не для тактических решений…

Да, это уже другой кейс. Эти десять тикетов ведь не связаны — это суть один и тот же тикет.
В нашем багтрекере это зовётся «дупликатами». И — да, мы сразу все, кроме одного основного, закрываем, при этом автоматически подписывая авторов дубликатов на уведомления по основному тикету

>о одник кликом открыть видеочат с тестировщиком, сказать голосом «так, покажи мне этого кота» и, потратив по 3 секунды времени разработчика и тестировщика получить всю ту же информацию

Да, но что с ней делать потом?
Если у вас zero bugs, и вот именно сейчас других багов нет — чудесно! Баг будет прям сразу же и починен.
Но что если это случилось сразу перед/сразу после выпуска новой версии, и других багов висит навалом, с более высоким приоритетом?
И очередь фикса подойдёт только через две недели?
Даже во время внутренней дискуссии мне писали про это сразу несколько человек :)

Практика “Заведи на меня (заведу на себя) карточку в трелло с описанием проблемы без детального описания (ведь мы же оба будем ‘помнить’ о чем она, когда до нее руки дойдут)” так же очень порочна и должна пресекаться при первых же мыслях о ней.

В терминах Андрея оба участника на момент записи карточки знают где сейчас кот, а спустя время как правило забывают даже кого искать — кота или собаку.

Про заведение уже согласованных багов
Да, я не сказал сразу, что баги хорошо бы сначала проговаривать с человеком в теме.
Но:

баг будут читать и другие люди. Списки багов просматривает потом зачастую весь сквад, включая разработчиков, суппортёров и техрайтеров
И каждый из них будет искать кота, потому что с одним каким-то человеком решили, что он поймёт и так.
даже этот понимающий человек через месяц тоже не вспомнит (Станислав меня опередил на минуту, чорт.)

Я бы от себя ещё добавил, что проблемы желательно описывать так, чтобы ты сам через месяц мог понять, что там в баге написано, когда детали забудешь

А ещё бывает, что его за эти две недели пофиксил кто-то другой, как сайд эффект от починки другой проблемы / рефакторинга / нечаянно.

Могу дополнить. Очень часто приходится не только “искать кота на картинке” но и проверять что “кота на картинке больше нет”. И в этом случае steps to reproduce и expected results вдвойне полезны.

Но — да, аргументы в пользу быстрой коммуникации и мгновенного фикса тоже были.

Именно поэтому баг лучше всего фиксить сразу. Кроме теории разбитых окон, которая тоже важна, здесь простая экономика.

В этом треде описывается как лучше всего зафиксировать понимание сути бага на потом. Но имея это понимание и разработчика, способного пофиксить этот баг, или хотя бы написать юнит тест, воспроизводящий его, фикс может занять меньше времени и энергии, чем запись этого бага.

Важно помнить что результатом всего процесса является отсутствие бага. А не скриншоты, тексты и примеры. Поэтому, я считаю, важно пытаться перед записью бага поговорить с разработчиком, и возможно, сразу пофиксить его.

Просто не всегда получается.