one_eight_seven

И? Где требованиеп в ACCESS держать PENABLE высоким? То, что PENABLE можно поднимать только в ACCESS state - это есть. А обратное? Это насколько надо не дружить с логикой, чтобы "не раньше, чем через один такт", понимать как "обязательно всегда через один такт"?

Это согласно какой спецификации? В AMBA даже близко нет такого требования

Если нужна трассировка, то посмотрите спецификацию на ATB. Если нужно именно отслеживание статуса - посмотрите как в сетевых устройствах сделаны счётчики статистик в случае одиночного ускорителя или сервера статистик в случае множества ускорителей с централизованным управлением

И как там, в радужном мире, где живут пони и какают радугой? Если инвестируют, когда ты заявляешь, что пользуешь агиле, то будешь заявлять, и заниматься очковтирательтсвом, что пользуешь. Посмотрите игропром и необходимость сотрудничать со Sweet Baby Inc, чем занимаются все крупные компании, и посмотрите, приносит это доходы или убытки. То же самое с индустрией кино и анимации. То же самое в технических монопольках.

Да. И даже state of agile об этом уже начал говорить. А это - коммитет, где все занимаются тем, что на этой инфоцыганщине зарабатывают. А те, кто с этим работает давным давно уже открыто обо всём говорят. Единственная вещь, которая ни у кого не вызывает отторжения - это CI/CD, но вот проблема - это не Agile. Его туда приписали для очковтирательства, но его можно легко приписать и к любой не-agile технологии.

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

У вас там что, 2012? Даже создатели агиле и скрума уже избегают этих слов, как полностью себя дискредетировавших.

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

Протокол разногласий придумали задолго до дебильной терминологии, и задолго до того, как waterfall, не имеющий ничего общего с имеющимися практиками и стандартами разработки на второй страничке той самой книги. И, конечно же - до того, как влажные фантазии начали с ним сравнивать

Нет, скорее сегодня - это взять только понятное из Scrum (оно же - плохое и перечислено ниже), криво его применять и пользоваться JIRA. Ничего из этого не имеет ничего общего ни с управлением проектами, ни с выполнением задач, ни, тем более, - с управлением изменениями в требованиях. Кстати, сам scrum - весьма неплох, даже хорош, надо всего лишь убрать из него спринты, скрам-мастера, продакт овнера, бэклог, спринт ревью, упоминания подотчётности (accountability) и обязательств (commitment), ну и сертификацию. Что тогда плохого останется в скрам?

QIS - маршут для visualizer, собирает qwave.db

угу. и модификатор final на класс. Я тоже против тривиальных методов, но всё-таки это какой-никакой, но задел на будущее.

Да всем можно. Код так более читаем для большинства людей. Плюс не надо думать и запоминать правила - всегда пишешь одинаково, и думаешь о том, как правильнее назвать. Если занимаешься интересными вещами, то заниматься подсчётом строк, вспоминать как по разному оформлять одинаковые по своей сути сущности - отвлекает. Поэтому, в библиотеках, да и во многих программах просто пользуются минимальным набором правил. по оформлению. Типа всё константное - ALL_CAPS_SNAKE (и-то не обязательно), всё остальное - lower_case_snake, или вообще всё - lower_case_snake Код может быть написан читаемым и в lower_case и в CamelCase, в стиле кодирования важнее другие вещи - правильное именование, объединение того, что должно быть объединено, и разделение разных сущностей по естественным границам, малые методы, делающие одно действие, понятно и явно написанные; комментарии, описывающие намерение или предупреждающие о чём-либо, а не реализацию (будто реализацию из кода не видно)

Это вы не поняли, что буковка e перед eEN1 или eEN2 - вообще ничего не поменяет. Более того, вы и читать не умеете. Я же сказал, компилятор - выругается, программист увидит, и поправит: test.cpp: In function ‘int main()’: test.cpp:12:13: error: ‘EN0’ was not declared in this scope 12 | int i = EN0; | ^~~ test.cpp:12:13: note: suggested alternatives: test.cpp:8:5: note: ‘B::EN0’ 8 | EN0, EN1 | ^~~ test.cpp:4:5: note: ‘A::EN0’ 4 | EN0, EN1 | ^~~ avi@mob:~/test$ Ещё раз призываю эволюционировать, сначала самому попробовать что-то сделать, а не постить влажные фантазии с апломбом гуру.

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