Попробуйте отключить в настройках «Исправлять две заглавные буквы в начале слова» и «Исправлять случайное нажатие Caps Lock», а в винде настроить отключение режима Caps Lock клавишей Shift. Это в комбинации решило похожую проблему у меня: при полностью отключенной клавише Caps Lock, сам Caps Lock иногда включается, а выключить нельзя (клавиша же отключена).
Когда-то в ШК было закодировано ровно то, что написано под ним — код-идентификатор чека (009.0256.061217.007).
Но такой ШК в Code 39 не помещался на чековую ленту 57 мм, поэтому формат кода-идентификатора изменился на более емкий, содержащий все те же данные, но в более компактном виде (05CB1AP.0JZARH).
Для совместимости с человеком и цифровыми клавиатурами расшифровка ШК осталась прежней.
Расскажите, как в вашем случае с вашим инструментом реализуется возможность посмотреть структуру базы данных на определенном коммите в SCM?
Часть существующих решений предлагает хранить только миграции и нулевую версию схемы, часть предлагает свой вариант DDL и генерацию миграций из его диффа.
Увольнял дважды: один раз на испытательном сроке, второй раз «вечного джуниора» через год в команде и пяти лет в компании. Считаю, что уволенного сотрудника нужно отлучать от команды как можно раньше, в идеале в тот же день (за исключением попавших под сокращение).
Самого увольняли по массовому сокращению в 2009, но в предпоследний рабочий день нашли проект и предложили остаться (сейчас думаю, что было опрометчиво не найти к этому дню работу).
Если ревьювер вносит какие-то мелочи, то просто берет и вносит. Если у него гениальная идея, как все переписать с нуля, то тут стоит задуматься над целесообразностью.
Изменения «средней тяжести» валидируются с автором. До или после во многом зависит от уровня погружения в код ревьювера и автора. Опытный в этой части кода ревьювер может что-то переделать и потом рассказать автору.
У нас есть нерешенная проблема: нет четкой границы, когда ревью с косметическими правками превращается в полную переработку авторского решения. Нужен какой-то объективный критерий, по которому можно оценить — стоит ли сейчас вносить это изменение или можно выпустить фичу в таком виде в релиз.
Да, бывает. Как раз в тех местах, где с первого взгляда непонятно, что так специально было сделано и есть какой-то дикий нюанс бизнес-логики, внешнего API, legacy-кода, а не просто продолбали. Специальной защиты от этого нет: явно отразить в коде эту особенность, добавить на нее тест, написать комментарий в конце концов. Никто не запрещает привлечь автора и попросить разъяснить непонятное.
Done-консилиум это еще не итоговое демо по результатам спринта, а внутренняя мини-демонстрация. Автор еще будет вносить изменения после него, поэтому ревьювить код рано. Done-консилиум обеспечивает минимальное погружение в выполненную задачу — без этого нельзя нормально выполнить ревью.
Если по итогам ревью было сделано много изменений, есть смысл провалидировать их с автором, но отдельного Done-консилиума нет.
Как уже писал, глубина погружения на практике может быть разной: кто-то пару проверок добавит, кто-то лишнего уберет, а кто-то обсудит с автором и отрефакторит API.
Мы как раз с классическим код-ревью ощущали проблему с выныриванием и заныриванием: автор запилил фичу и хочет пилить следующую, но остальным некогда поревьювить, потому что у них тоже фичи интересные, но когда они посмотрят, то автор уже начал новую и ему снова переключаться обратно.
Сейчас ревьювер один и он посмотрит тогда, когда ему будет удобно, но при этом не начнет новую задачу, пока не поревьювит. Автор же сразу переключается на новую задачу.
Нам никто не мешает иногда работать по такой схеме с одним днем для обсуждений в неделю или даже без них вообще.
Это дает прирост производительности сейчас, но копит неразгрумленные задачи. Нормальный компромисс, когда PO и команда немного расходятся в понимании, что можно и что нужно успеть в очередном спринте.
1. Да, все правильно сказали. Но мы сталкивались ситуацией, когда-то кто-то из команды уже после код-фриза или прямо на демонстрации понимал, что в задаче коллеги можно было бы еще что-то важное учесть.
А вся команда должна быть довольна, чтобы ни у кого не было ощущения, что кто-то рядом запилил какую-то фигню (пусть и рабочую), с которой теперь жить :-)
2. Вы правы, погружение в контекст требует времени больше, чем исправление самим автором, поэтому на практике глубина погружения может быть разной (в зависимости от загруженности).
По моим ощущениям, оверхеда не больше, чем при парном программировании, для которого как раз не всегда достаточно времени.
В нашем случае эти штуки сформированы самой командой в ответ на имевшуюся у каждого боль.
Основной посыл для менеджмента при внедрении всего этого: разработчики любят писать код и здоровая команда без лишних отвлечений может делать больше и лучше.
Идея, что разработчики сами закроют функциональное тестирование не взлетела.
Перед тем, как уйти на новый проект, мне пришлось взять в команду толкового автотестировщика, чтобы не уронить качество.
В то время, когда разработчики пишут функциональные тесты, они не пишут код. Как следствие:
1. разработчики хотят писать код, а не тесты;
2. бизнес хочет, чтобы разработчики писали код, а не тесты;
3. никто не хочет тесты.
В моей новой команде выделенная роль автотестировщика была запланирована сразу.
За наличие такой возможности (имитация своих же фискальных документов) фискальный регистратор просто не попадет в Государственный реестр контрольно-кассовой техники, либо может быть исключен из него => не сможет быть поставлен на учет в налоговой и использоваться торговыми предприятиями => не будет продаваться. То есть это зона ответственности и головная боль производителя.
Напечатать такой же на вид документ с помощью любых других средств — пожалуйста, ничто не помешает. Главное, чтобы фискальный регистратор не давал возможности напечатать на нем же нефискальный документ с фискальным признаком.
Устройства, приведенные выше, решают эту задачу по-разному:
1. Пирит ФР01К (чек слева) печатает по краям нефискального документа вертикальные полосы, которые сразу делают документ непохожим на фискальный кассовый чек.
2. Pirit K полосы не печатает, но не позволяет вывести произвольную графику в той области, где на чеке находится фискальный признак.
Я согласен с тем, что разработчик побывавший хотя бы раз поздно вечером на запуске на объекте клиента, в последствии более трепетно относится к качеству своей работы. Но сам факт позднего выявления ошибки это повод для оперативных действий по устранению последствий и тема для ретро, а не повод для линчевания.
Нам повезло и наша функциональная область чаще всего позволяет рассматривать GUI только как инструмент для совершения нужных действий с минимальной необходимостью валидации (есть/нет, включен/отключен).
Интервьюер тоже человек, мог ещё не до конца отладить формулировку и будет рад обратной связи)
Попробуйте отключить в настройках «Исправлять две заглавные буквы в начале слова» и «Исправлять случайное нажатие Caps Lock», а в винде настроить отключение режима Caps Lock клавишей Shift. Это в комбинации решило похожую проблему у меня: при полностью отключенной клавише Caps Lock, сам Caps Lock иногда включается, а выключить нельзя (клавиша же отключена).
Когда-то в ШК было закодировано ровно то, что написано под ним — код-идентификатор чека (
009.0256.061217.007).Но такой ШК в Code 39 не помещался на чековую ленту 57 мм, поэтому формат кода-идентификатора изменился на более емкий, содержащий все те же данные, но в более компактном виде (
05CB1AP.0JZARH).Для совместимости с человеком и цифровыми клавиатурами расшифровка ШК осталась прежней.
Попробуйте отсканировать Code 39 ШК внизу чека из Ленты, Окея или Призмы и убедитесь, что это не совсем так :-)
Расскажите, как в вашем случае с вашим инструментом реализуется возможность посмотреть структуру базы данных на определенном коммите в SCM?
Часть существующих решений предлагает хранить только миграции и нулевую версию схемы, часть предлагает свой вариант DDL и генерацию миграций из его диффа.
Самого увольняли по массовому сокращению в 2009, но в предпоследний рабочий день нашли проект и предложили остаться (сейчас думаю, что было опрометчиво не найти к этому дню работу).
Изменения «средней тяжести» валидируются с автором. До или после во многом зависит от уровня погружения в код ревьювера и автора. Опытный в этой части кода ревьювер может что-то переделать и потом рассказать автору.
У нас есть нерешенная проблема: нет четкой границы, когда ревью с косметическими правками превращается в полную переработку авторского решения. Нужен какой-то объективный критерий, по которому можно оценить — стоит ли сейчас вносить это изменение или можно выпустить фичу в таком виде в релиз.
Done-консилиум это еще не итоговое демо по результатам спринта, а внутренняя мини-демонстрация. Автор еще будет вносить изменения после него, поэтому ревьювить код рано. Done-консилиум обеспечивает минимальное погружение в выполненную задачу — без этого нельзя нормально выполнить ревью.
Если по итогам ревью было сделано много изменений, есть смысл провалидировать их с автором, но отдельного Done-консилиума нет.
Мы как раз с классическим код-ревью ощущали проблему с выныриванием и заныриванием: автор запилил фичу и хочет пилить следующую, но остальным некогда поревьювить, потому что у них тоже фичи интересные, но когда они посмотрят, то автор уже начал новую и ему снова переключаться обратно.
Сейчас ревьювер один и он посмотрит тогда, когда ему будет удобно, но при этом не начнет новую задачу, пока не поревьювит. Автор же сразу переключается на новую задачу.
Нам никто не мешает иногда работать по такой схеме с одним днем для обсуждений в неделю или даже без них вообще.
Это дает прирост производительности сейчас, но копит неразгрумленные задачи. Нормальный компромисс, когда PO и команда немного расходятся в понимании, что можно и что нужно успеть в очередном спринте.
А вся команда должна быть довольна, чтобы ни у кого не было ощущения, что кто-то рядом запилил какую-то фигню (пусть и рабочую), с которой теперь жить :-)
2. Вы правы, погружение в контекст требует времени больше, чем исправление самим автором, поэтому на практике глубина погружения может быть разной (в зависимости от загруженности).
По моим ощущениям, оверхеда не больше, чем при парном программировании, для которого как раз не всегда достаточно времени.
Основной посыл для менеджмента при внедрении всего этого: разработчики любят писать код и здоровая команда без лишних отвлечений может делать больше и лучше.
Или у вас анархия в самой команде?
Перед тем, как уйти на новый проект, мне пришлось взять в команду толкового автотестировщика, чтобы не уронить качество.
В то время, когда разработчики пишут функциональные тесты, они не пишут код. Как следствие:
1. разработчики хотят писать код, а не тесты;
2. бизнес хочет, чтобы разработчики писали код, а не тесты;
3. никто не хочет тесты.
В моей новой команде выделенная роль автотестировщика была запланирована сразу.
Устройства, приведенные выше, решают эту задачу по-разному:
1. Пирит ФР01К (чек слева) печатает по краям нефискального документа вертикальные полосы, которые сразу делают документ непохожим на фискальный кассовый чек.
2. Pirit K полосы не печатает, но не позволяет вывести произвольную графику в той области, где на чеке находится фискальный признак.
Есть фискальные регистраторы, у которых вместо ФП другой графический символ, который нельзя напечатать обычными шрифтами.
Пирит ФР01К и Pirit K:
Сорри, конечно же, увеличивает время, а не скорость :-)