Myclass

транзисторы? Т.к. транзисторы - не есть логические гаттеры

Если для галочки- то да, такое встречал. И не только в виртуальном режиме. Но по-насооящему, нет, такое не возможно.

И добавлю. Такой PM по совместительству ещё и скрам мастером был.

А зачем второе делать? Ведь тем, что передаётся значение как параметр, то создаётся string по любому, а потом переобразовывается , те используется конструктором - опять в string. Хотя может быть для компайлера разницы нет.

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

Я понимаю, что автор вопроса новичёк в этих темах, и думаю не получится -но попробую на двух словах обьяснить. Появилась свободная минута...

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

Очень часто показатели собираются снизу, т.е. с низшей ступени. И как в вашем случае - из логов.
Вот представьте себе каждый из ваших филиалов продаёт различные продукты. Т.е. по каждому продукту и дню, когда он был продан - можно отчитаться. Теперь представьте себе, это делают не только по дням, но и например недельные показатели продаж. Но именно по филиалам. Предстаьте себе центральную квартуру этой фирмы с различными филиалами. И из каждого из них текут сведения по продажам. Например месячные сведения. Т,е. в центральном оффисе никогда никто не сможет сказать, сколько было продано во всех филиалах вчера, позавчера итд. Потому что уровень аггрегации очень груб. Это точно также, как топором часы ремонтировать. И если возникает задача, более точные статистики в центре делать, значит уровень подачи данных будет не месячный, а каждодневный. Вроде-бы хорошо. Но за счёт того, что сведения идут каждый день, увиличивается обьём данных, которые надо постоянно суммировать в центре.

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

Т.е. идногда делают компромисс. И оговаривают, где и на каком уровне делается своя статистика, которая потом стекается со всех филиалов и какая статистика делается там.

И чем ниже уровень, где создаются данные о продажах, использовании итд. , то тем больше данных надо обработать. Но ведь только своих. А потом в сжатом виде они передаются дальше по цепочке. Но всё равно например по каждому продуку. Там-же в свою очередь информации о конкретном продукте искуственно заменяется например на класс продукта. Для этого где записывается какому классу принадлежит каждый продукт. Т.е. общая статистика по 10000-и продуктам заменяется на 10-классов и именно эта статистика используется в эшелонах выше.

Рассчёт по филиалу:
Продаётся 1000 продуктов каждый день. Те. в центр отсылается 1000 записей каждый день. Много это или мало - все образно. Если эти продукты заменяются на классы, то каждый день будут посылаться например 10 цифр из каждого филиала. Что много меньше, но тогда никто в центре не будет знать, что лучшим продавцом сегодня был Петя Васечкин. Потому что нет у них этой информации. И для глобальных решений эта информации и не нужна.

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

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

Почему-то думаю, что никак. В этом-то и суть agile - не думать о глобальных проблемах, которых сегодня вроде-бы как и нет. Оно вроде-бы звучит правильно. Но всегда надо над архитектурой больше думать ,чем это требуют требования сегодня. Но. Это низя.

Мой совет - требование в топку. Хотя, если подумаешь ;). Но ведь без него тоже будет никак. Ну тогда выводится n-кол-во людей из под agile и они делают перезализ новой архитектуры в новой ветке. Это конечно-же те ещё грабли и обе ветки координировать - мало удовольствия. Увы - демаю рецепта нет.

Потому что нельзя помыться и не намочиться. А все этого только и хотят.

Создаёшь цикл и в нём вызываешь InputBox. Но я-бы не делал это через диалог. Причин много. Например сбились. Всё повторять? Уверен, что проще в новой/другой таблице для этого выделить столбец и все значения, которые там лежат - переводить в array.

А вы понимаете слово степень?
Ведь это просто n-ое кол-во раз число умножается на себя. И первая часть до плюса это и воспроизводит. Вторая часть после плюса есть и есть тот плюс из формулы.