Пером выделяются блоки текста с интересными мыслями.
Если с читалкой все ок, то эти блоки легко экспортировать и потом построить на основе них майнд карту.
Если то же самое делать с помощью джойстика, то это отдельная и очень грустная песня
Я скажу, что да нужен.
Правда задачи для такого ридера специфические, проф литература и комиксы :)
Так что боюсь рынок для таких устройств не сильно широк.
Сам пользуюсь ONYX BOOX M92SM TITAN, здоровый и тяжелый, в метро не удобно. Но для pdf сверстанных под а4 практически идеален.
Что касается отсутствие перьевого ввода это и плюс и минус. Минус в том, что активное чтение становиться пыткой.
Коллега, что вы хотите услышать?
Доказать?
Можно бесконечно придумывать сложности и почему это плохо.
Или почему нельзя тестировть архитектуру…
Какой вы хотите получить ответ?
С чайником, например, его отрисовали, и тестировщики посмотрели и спросили.
Чайник красивый, но крышка так сделана, что мы не сможем стенд который ее будет открывать и закрывать автоматически. Мы не сможем провести ресурсные испыания. А это важно. И крышку меняют.
Выводы вполне очевидны и многими давно используются:
Разработка и тестирование должны начинаться и заканчиваться практически одновременно (этим обычно занимается отдел QA). Идеальный вариант, когда вся разрабатываемая функциональность к моменту готовности уже покрыта автотестами, организованными в регрессионное (а по возможности и пред-коммитное) тестирование с помощью какого-нибудь CI.
Не совсем, тестирование должно начинаться раньше. Хорошо когда тестирование начинается тогда же когда ведется разработка требований(SRS).
Идеально если в момент разработки архитектуры
Чем больше в проекте фич (чем он сложней) тем больше времени придется тратить на проверку того, что новая функциональность не поломала старой. Отсюда чем сложней проект — тем больше требуется автоматизации регрессионного тестирования.
И да и нет. Очень зависит от многих факторов.
Матрицы влияния сильно упрощают жизнь.
И опять же насколько у вас хорошо поставлен процесс QA, не тестирования, а именно QA
Каждый раз, когда мы пропускаем баг в продакшн, и пользователь его находит, — нам приходится тратить дополнительное время на прохождение по жизненному циклу проекта начиная с п.1 (Работа с требованиями, в данном случае, пользователей). Так как причины пропуска бага в общем случае неизвестны, нам остается только один путь оптимизации — каждый, найденный пользователями баг должен быть включен в регрессионное тестирование, чтобы быть уверенным, что больше он не появится.
В зависимости от многих факторов… И не должен и не каждый… Поскольку это дорого!
Одна тонкость, слепнет на солнце. В остальном согласен.
Пером выделяются блоки текста с интересными мыслями.
Если с читалкой все ок, то эти блоки легко экспортировать и потом построить на основе них майнд карту.
Если то же самое делать с помощью джойстика, то это отдельная и очень грустная песня
Правда задачи для такого ридера специфические, проф литература и комиксы :)
Так что боюсь рынок для таких устройств не сильно широк.
Сам пользуюсь ONYX BOOX M92SM TITAN, здоровый и тяжелый, в метро не удобно. Но для pdf сверстанных под а4 практически идеален.
Что касается отсутствие перьевого ввода это и плюс и минус. Минус в том, что активное чтение становиться пыткой.
Я поэтому и говорю, что WF — это миф. Обычно WF — обзывают именно проектный подход с выделенными этапами, которые идут последовательно.
Ссылочку можно на описание :)
Эту можно не предлагать: ru.wikipedia.org/wiki/%D0%9A%D0%B0%D1%81%D0%BA%D0%B0%D0%B4%D0%BD%D0%B0%D1%8F_%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D1%8C
Нет там ничего :)
Кстати верно и обратное…
Доказать?
Можно бесконечно придумывать сложности и почему это плохо.
Или почему нельзя тестировть архитектуру…
Какой вы хотите получить ответ?
С чайником, например, его отрисовали, и тестировщики посмотрели и спросили.
Чайник красивый, но крышка так сделана, что мы не сможем стенд который ее будет открывать и закрывать автоматически. Мы не сможем провести ресурсные испыания. А это важно. И крышку меняют.
Не совсем, тестирование должно начинаться раньше. Хорошо когда тестирование начинается тогда же когда ведется разработка требований(SRS).
Идеально если в момент разработки архитектуры
И да и нет. Очень зависит от многих факторов.
Матрицы влияния сильно упрощают жизнь.
И опять же насколько у вас хорошо поставлен процесс QA, не тестирования, а именно QA
В зависимости от многих факторов… И не должен и не каждый… Поскольку это дорого!