Давно уже не наблюдал адекватно построенного прогресс-бара. (Который движется равномерно и реально отображает ситуацию с процессом). Часто еще бывает, что прогресс-бар пробегает до конца, потом начинается снова и снова… и снова, со все новыми леденящими душу комментариями (расаковка, запаковка, регистрация компонентов, удаление чего-то-там и тд.). Бывает зависает намертво на последних процентах. Бывает долго не может начать движение.
Все это — полная профанация идеи прогресс-бара, как средства взаимодействия компьютера с человеком. Думаю — основная причина — лень разработчиков реально оценить временные затраты на полный процесс, а также хоть немного времени потратить продумывание поведения этого очень важного в плане юзабилити элемента интерфейса. Конечно, бывают случаи, когда время действительно сложно оценить, но думаю, что даже в этом случае грамотный подход может значительно улучшить поведение прогресс бара.
Иногда бывает, что IDE-отладчик не справляется с кодом, генерируемым в режиме оптимизации. Оптимизатор же в Delphi может делать очень интересные вещи — может например, перевернуть цикл вверх ногами (i заменить на n-i). Не удивлюсь, если он и с булевскими значениями может что-нибудь сделать. Рекомендую при отладке снимать галочку оптимизация в компиляторе. (Хотя может в данном посте — не этот случай, но то, что глюк исчез при пересборке проекта очень напоминает ситуацию с оптимизацией)
Конечно!!! Очень ценное замечание. Ради этого все и задумывалось. В Demo4. (Построение тетраэдра) в самом начале переменной присваивается размер стороны. Все остальные координаты вычисляются из нее. Параметрическое моделирование здесь получается естественно, если придерживаться определенных правил при построении. Кроме того, можно использовать процедуры (как в Demo3). При этом написав один раз построение объекта, как процедуру можно вызывать эту процедуру сколько угодно раз с разными параметрами.
Согласен. Система предполагает навыки в программировании. Но при этом открывается масса возможностей. Можно строить интересные математические объекты, которые мышкой не построить при всем желании. Данная система больше задумывалась как-раз для такой науко-содежащей графики. И конечно, ручной редактор для меня реализовать было сложно. Соревноваться с 3DMax я бы не рискнул.
Рад, что данный пост оказался Вам полезен. Библиотека x3dom строится на декларативном описании сцены с помощью тегов. В некоторых случаях это удобно, в некоторых — ограничивает. Но в целом было приятно работать с ней.
Как Вы поняли, что Ragel выдает нестабильный код? Я в том смысле, в каких обстоятельствах у Вас закрались первые сомнения о том что он работет нестабильно?
Сейчас даже в среднем проекте используется огромное количество уже написанного кода (т.е библиотек). Конечно можно попробовать изучить их все и оттестировать, но думаю, это малореально (если еще учитывать и платформы на которых они исполняются). Лучше эти усилия потратить на покрытие тестами непосредственно продукта который разрабатывается непосредственно Вами. При тестировании всего продукта вскроется и некорректное или странное поведение библиотек, если таковое имеется. Может вполне случится, что даже недостаточно надежная библиотека работает в проекте хорошо, потому что Вы не затронули неправильно реализованных функций.
Да, наверное для первого числа в числителе должен быть 0 (количество целых дней прошедшее с начального момента месяца). Можно также продолжить этот ход мыслей. Раз уж функция Real нужно идти до конца (учитывать также и время). Тогда в числителе будет количество секунд (или более мелких единиц) прошедшее с начала месяца (01.XX.XXXX 00.00), а в знаменателе — длина соответствующего месяца в секундах (или более мелких единицах).
Думаю, что задача не соответствует названию книжки: «Пятьдесят занимательных вероятностных задач с решениями». И сама задача и приведенное решение лежит в области психологии. Любимые, счастливые и несчастливые числа, предпочтительные цвета — это все оттуда.
Спасибо за комментарий. Закон как всегда расставляет все на свои места.
Про високосную секунду я знал. А про зимнее и летнее время просто не подумал.
Наверное, закон и здесь может подсказать какое-нибудь верное решение.
В частности, меня интересует вопрос, как должен выглядеть отчет о каком либо параметре, меняющемся каждый час
за сутки, когда переводится время? Сколько в нем должно быть записей (11, 12 или 13)
и чего в них должно быть написано в графе время?
Я пользуюсь «Презумпцией невиновности». Считаю, что библиотеки работают правильно. Когда начинают валится мои тесты моего кода, разбираюсь в чем дело, и если виновата библиотечная функция, то добавляю тест (как Вы правильно заметили для отслеживания этого бага в будущих версиях). Иногда, и довольно часто, в случае разборок оказывается, что библиотечная функция работает правильно, это у меня мозги не в ту сторону развернуты. В этом случае правлю мозги, но тест все равно добавляю (теперь уже для моих мозгов).
Да, в разделе «Несколько слов в оправдание фирмы Borland» я говорю, что существуют случаи, когда поведение функции однозначно определить сложно, но дальше я объясняю, почему считаю подход фирмы Borland неверным. Моя реализация тоже страдает неоднозначностью, но я про это тоже сказал:
Я написал верную, с точки зрения моих требований, функцию
Что касается «На Delphi еще пишут?", могу лишь ответить, что проект был написан на Delphi, когда она была популярна. В рамках проекта было нужно доработать систему.
По большому же счету считаю Delphi удачной системой. Хорошая была задумка. Жаль, что ее популярность снизилась. С уважением отношусь к людям, которые делают OpenSource аналоги Delphi, в том числе и под Linux.
P.S. Когда писал и отлаживал код, компиляция и прохождение тестов на моем стареньком ноутбуке занимало всего несколько секунд. Было немного непривычно.
Все это — полная профанация идеи прогресс-бара, как средства взаимодействия компьютера с человеком. Думаю — основная причина — лень разработчиков реально оценить временные затраты на полный процесс, а также хоть немного времени потратить продумывание поведения этого очень важного в плане юзабилити элемента интерфейса. Конечно, бывают случаи, когда время действительно сложно оценить, но думаю, что даже в этом случае грамотный подход может значительно улучшить поведение прогресс бара.
Про високосную секунду я знал. А про зимнее и летнее время просто не подумал.
Наверное, закон и здесь может подсказать какое-нибудь верное решение.
В частности, меня интересует вопрос, как должен выглядеть отчет о каком либо параметре, меняющемся каждый час
за сутки, когда переводится время? Сколько в нем должно быть записей (11, 12 или 13)
и чего в них должно быть написано в графе время?
Что касается «На Delphi еще пишут?", могу лишь ответить, что проект был написан на Delphi, когда она была популярна. В рамках проекта было нужно доработать систему.
По большому же счету считаю Delphi удачной системой. Хорошая была задумка. Жаль, что ее популярность снизилась. С уважением отношусь к людям, которые делают OpenSource аналоги Delphi, в том числе и под Linux.
P.S. Когда писал и отлаживал код, компиляция и прохождение тестов на моем стареньком ноутбуке занимало всего несколько секунд. Было немного непривычно.