Судя по вашей табличке, количество ядер на процессор, наоборот, упало примерно в 2.5 раза. И тактовая частота тоже. Это означает гораздо больше занимаемый объём этой махиной
Заявлено: "как за 8 часов исследовать продуктовый сценарий, нагенерить идей и взяться за макеты". Реально: всё есть, "Заказчик отметил моменты, которые надо доработать" на готовом превью, над которым целая команда работала 3 месяца.
Проблемы на входе? Неизвестны, поэтому зачем и почему всё дальше делает ТС - читатель должен сам догадаться. Я не догадался, ибо нет времени.
Результат? Много разноцветных разномастных элементов, стрелочек на трёх скринах. Я опять туплю, но времени вникать нет. Понятно сформулирована только нерешённая проблема
Крайне скептически отношусь к полезности корпоративных блогов, но этот пост очень содержателен. Правда, не всё нужное увидел (например, структуру доков для управления функциональными требованиями/описаниями). В целом очень здорово. Многие большие команды, которые видел, сильно не дотягивают до уровня этого поста.
Из личного. Год или два назад вакансии аналитиков в Спорт-Мастер запомнились как крайне скучные и формальные. Вероятно, что-то изменилось
О чём и речь. Вы сами зафиксировали, что все варианты оканчиваются одним остановом (завершением процесса) - так соблюдайте же это. Вы понимаете, что один останов и три останова - это, соответственно, одна и три независимые сущности в системе? Вам проще контролировать одну точку или три? Что за содержание между ветвлением и окончанием этого ветвления - вообще не важно, артефакт или суперсложный подпроцесс. Но если вы сейчас, как нарисовали, отпустите на волю этот подпроцес, вы легко и непринуждённо вернётесь назад (плодя логические петли), совершенно забыв про обязательное условие - зафиксировать результат ветвления в собирающем шлюзе.
В реальных системах мы обязаны соблюдать формальную логику, а не "и так же очевидно, чё тут усложнять". Потому что она не для красоты, а для контроля (человеком или движком) начала и завершения всей модели. Поэтому такие примеры, на мой взгляд, вредны.
Тут другие читатели верно заметили про первый пример, где так легко и непринуждённо упущен собирающий шлюз. Это нарушение логики, потенциально ведущее к потерю контроля за процессом.
Решается просто. Что общее у вариантов? Завершение - значит, его оставляем. Собирающий шлюз для соблюдения формальной логики. А что надо, чтобы показать то, что хочет автор? Просто зафиксировть результат процесса, например, доком (артефактом) в каждом варианте. Это гораздо правильнее, потому что в реальной системе комменты на схеме останутся комментами, а артефакт на схеме - это реальный запись в системе с результатом процесса
Сопротивление резистора R2 выше, чем R1, а это ограничивает возможность тока потечь через него
Если дословно верить фразе, то автору удалось придумать альтернативный закон Киргофа - от сопротивлений теперь зависит не сила тока, а его вероятность (возможность). А всего-то не надо вставлять слова-паразиты в технический текст.
Да, спасибо, понял вашу модель мира разработки. Резюме
Бизнес и разработка - это про проблемы и боль, а не про достижения новых целей. Только уменьшение или устранение этой боли. Команда разработки - это спасатели и врачеватели.
Сначала где-то в голове декомпозируем задачу проблему до разработки, на этапе разработки спохватываемся и начинаем обратную композицию, не потеряли ли что по дороге (ведь артефактов декомпозиции нет, потому что на этапе разработки "уже забывается", верно? Если бы они были, то при обязательной валидации каждого последующего шага декомпозиции обратная цепочка говорит лишь об профессиональном провале всех уровней анализа проекта)
По рис.2. Системы решают только проблемы? Просто задачи бизнеса они не решают?
Рис.4 противоречит содержанию всей статьи. Движение от разработки к решению задач бизнеса - как такое возможно? Собираются, значит, разрабы и давай разворачивать программные компоненты чтобы... и постепенно так рождаются задачи бизнеса. Прямо пластилиновый мультик
Когда-то давно тратил часы для бытовых задач (сложные групповые переименования), чтобы разобраться в этом адовом скпоплении символов. Как правило, безуспешно. И какая прекрасная эра наступила сейчас! Формулирую ИИ, вставляю какой-тоужасныйнаборнепонятночего в нужную программку - и всё, программка выдаёт нужный результат.
Если что, я, конечно, реально преклоняюсь перед теми, кто в этом как в воде. Но это надо иметь очень продвинутый мозг...
У домена нет ограниченного контекста - значит, что или домен не имеет контекста, или контекст не ограничен. В 1-м случае домен перестаёт существовать, т.к. ничего не содержит. Отметаем. Во 2-м случае мы можем напихать в контекст что угодно. В приведённом примере можно добавить, что компания занимается майнингом и торговлей криптовалюты для обеспечения закупок и взаиморасчётов. Теперь ваш домен включает приличный кусок деятельности, обеспечение которой может затмить (заменить, угробить) поставленную цель.
Так есть у домена свой ограниченный контекст или нет? Пока не понимаю, почему ограниченный контекст внезапно появляется только в поддоменах
Тут я приготовился увидеть резюме статьи для лентяев типа меня. И... вижу какие-то общие слова и какое-то изречение для камня. Т.е. вся статья, с уймой технических подробностей и типа смешными картинками, была написана, чтобы в финале дать наставления читающим?!
В хендбрейке те же опции, что и в статье, только через ГУИ.
Ну, у автора же посыл, что к чёрту все эти удобные штуки, побежали в командную строку, там всё гораздо интереснее
При CRF-кодировании ограничение битрейта нужно для того чтобы новая порция данных успевала считаться с диска или загрузиться по сети, а также учитывается размер буфера на плеере
Мы же говорим про кодирование, а не про воспроизведение? Каким образом я, перекодируя видео, могу предвидеть, какой там буфер у заранее неизвестного плеера и какие там скорости будут у совершенно мне неведомого носителя?
В общем, я впервые слышу, что при выборе CRF надо учитывать параметры носителя и плеера. Возможно, для специальных случаев, но явно не "для дома, для семьи". Не могу представить, чтобы HDD даже 10-15 летней давности (SATA-II, правильно помню?) не тянули полноценный блюрей, не говоря уже о пожатых видео
указание большего или меньшего значения CRF в большей степени зависит от скорости вашего накопителя, нежели от процессора
Какое отношение уровень качества видео имеет к скорости накопителя? Вообще никакого. В худшем случае, от скорости накопителя будет зависеть скорость кодирования, но никак не CRF.
В целом, статья совсем не убедила перейти с Handbrake или StaxRip на предложенную командную строку
Пример Use Case содержит ряд грехов по версии всех религий, кроме ленивой.
Актор висит в вакууме, выбрает товары в вакууме и т.п. Если свою систему не причисляете к акторам (а зря), то надо указать, с чем взаимодействует один этот актор.
Система, по-видимому, обладает телепатией, раз знает, есть товар на складе или нет. Надо анализировать наличие товара в системе с признаком "склад", а не товар на складе - это очень грубая ошибка, какой бы суперавтоматизированной система ни была
Перевод кривой. Динамик не может быть ни BT, ни WiFi, не может иметь аккумулятор и т.п. А вот колонка (акустическая система) - может
Судя по вашей табличке, количество ядер на процессор, наоборот, упало примерно в 2.5 раза. И тактовая частота тоже. Это означает гораздо больше занимаемый объём этой махиной
Заявлено: "как за 8 часов исследовать продуктовый сценарий, нагенерить идей и взяться за макеты".
Реально: всё есть, "Заказчик отметил моменты, которые надо доработать" на готовом превью, над которым целая команда работала 3 месяца.
Проблемы на входе? Неизвестны, поэтому зачем и почему всё дальше делает ТС - читатель должен сам догадаться.
Я не догадался, ибо нет времени.
Результат? Много разноцветных разномастных элементов, стрелочек на трёх скринах.
Я опять туплю, но времени вникать нет. Понятно сформулирована только нерешённая проблема
Увидел
и на этом закончил.
Представляю, какая там каша дальше возможна, если сразу на взлёте чел базово не понимает про объектность/субъектность
Крайне скептически отношусь к полезности корпоративных блогов, но этот пост очень содержателен. Правда, не всё нужное увидел (например, структуру доков для управления функциональными требованиями/описаниями). В целом очень здорово. Многие большие команды, которые видел, сильно не дотягивают до уровня этого поста.
Из личного. Год или два назад вакансии аналитиков в Спорт-Мастер запомнились как крайне скучные и формальные. Вероятно, что-то изменилось
О чём и речь.
Вы сами зафиксировали, что все варианты оканчиваются одним остановом (завершением процесса) - так соблюдайте же это. Вы понимаете, что один останов и три останова - это, соответственно, одна и три независимые сущности в системе? Вам проще контролировать одну точку или три?
Что за содержание между ветвлением и окончанием этого ветвления - вообще не важно, артефакт или суперсложный подпроцесс. Но если вы сейчас, как нарисовали, отпустите на волю этот подпроцес, вы легко и непринуждённо вернётесь назад (плодя логические петли), совершенно забыв про обязательное условие - зафиксировать результат ветвления в собирающем шлюзе.
В реальных системах мы обязаны соблюдать формальную логику, а не "и так же очевидно, чё тут усложнять". Потому что она не для красоты, а для контроля (человеком или движком) начала и завершения всей модели. Поэтому такие примеры, на мой взгляд, вредны.
Тут другие читатели верно заметили про первый пример, где так легко и непринуждённо упущен собирающий шлюз. Это нарушение логики, потенциально ведущее к потерю контроля за процессом.
Решается просто.
Что общее у вариантов? Завершение - значит, его оставляем. Собирающий шлюз для соблюдения формальной логики. А что надо, чтобы показать то, что хочет автор? Просто зафиксировть результат процесса, например, доком (артефактом) в каждом варианте.
Это гораздо правильнее, потому что в реальной системе комменты на схеме останутся комментами, а артефакт на схеме - это реальный запись в системе с результатом процесса
Заголовки 3 и 4 (US и UC) перепутаны местами
Добавлю:
Если дословно верить фразе, то автору удалось придумать альтернативный закон Киргофа - от сопротивлений теперь зависит не сила тока, а его вероятность (возможность).
А всего-то не надо вставлять слова-паразиты в технический текст.
Вижу маленькую коробочку (слайд 2) с офигительной вычислительной мощностью и полным отсутствием принудительной вентиляции. Очень интересно
А мне немного странно, что вместо ответа по существу лезем в профиль человека и начинаем его обсуждать. Очень топорное поведение
Да, спасибо, понял вашу модель мира разработки. Резюме
Бизнес и разработка - это про проблемы и боль, а не про достижения новых целей. Только уменьшение или устранение этой боли. Команда разработки - это спасатели и врачеватели.
Сначала где-то в голове декомпозируем
задачупроблему до разработки, на этапе разработки спохватываемся и начинаем обратную композицию, не потеряли ли что по дороге (ведь артефактов декомпозиции нет, потому что на этапе разработки "уже забывается", верно? Если бы они были, то при обязательной валидации каждого последующего шага декомпозиции обратная цепочка говорит лишь об профессиональном провале всех уровней анализа проекта)По рис.2. Системы решают только проблемы? Просто задачи бизнеса они не решают?
Рис.4 противоречит содержанию всей статьи. Движение от разработки к решению задач бизнеса - как такое возможно?
Собираются, значит, разрабы и давай разворачивать программные компоненты чтобы... и постепенно так рождаются задачи бизнеса. Прямо пластилиновый мультик
Когда-то давно тратил часы для бытовых задач (сложные групповые переименования), чтобы разобраться в этом адовом скпоплении символов. Как правило, безуспешно. И какая прекрасная эра наступила сейчас! Формулирую ИИ, вставляю какой-тоужасныйнаборнепонятночего в нужную программку - и всё, программка выдаёт нужный результат.
Если что, я, конечно, реально преклоняюсь перед теми, кто в этом как в воде. Но это надо иметь очень продвинутый мозг...
У домена нет ограниченного контекста - значит, что или домен не имеет контекста, или контекст не ограничен.
В 1-м случае домен перестаёт существовать, т.к. ничего не содержит. Отметаем.
Во 2-м случае мы можем напихать в контекст что угодно. В приведённом примере можно добавить, что компания занимается майнингом и торговлей криптовалюты для обеспечения закупок и взаиморасчётов. Теперь ваш домен включает приличный кусок деятельности, обеспечение которой может затмить (заменить, угробить) поставленную цель.
Так есть у домена свой ограниченный контекст или нет?
Пока не понимаю, почему ограниченный контекст внезапно появляется только в поддоменах
Тут я приготовился увидеть резюме статьи для лентяев типа меня. И... вижу какие-то общие слова и какое-то изречение для камня.
Т.е. вся статья, с уймой технических подробностей и типа смешными картинками, была написана, чтобы в финале дать наставления читающим?!
Ну, у автора же посыл, что к чёрту все эти удобные штуки, побежали в командную строку, там всё гораздо интереснее
Мы же говорим про кодирование, а не про воспроизведение?
Каким образом я, перекодируя видео, могу предвидеть, какой там буфер у заранее неизвестного плеера и какие там скорости будут у совершенно мне неведомого носителя?
В общем, я впервые слышу, что при выборе CRF надо учитывать параметры носителя и плеера. Возможно, для специальных случаев, но явно не "для дома, для семьи". Не могу представить, чтобы HDD даже 10-15 летней давности (SATA-II, правильно помню?) не тянули полноценный блюрей, не говоря уже о пожатых видео
Какое отношение уровень качества видео имеет к скорости накопителя? Вообще никакого.
В худшем случае, от скорости накопителя будет зависеть скорость кодирования, но никак не CRF.
В целом, статья совсем не убедила перейти с Handbrake или StaxRip на предложенную командную строку
Пример Use Case содержит ряд грехов по версии всех религий, кроме ленивой.
Актор висит в вакууме, выбрает товары в вакууме и т.п.
Если свою систему не причисляете к акторам (а зря), то надо указать, с чем взаимодействует один этот актор.
Система, по-видимому, обладает телепатией, раз знает, есть товар на складе или нет. Надо анализировать наличие товара в системе с признаком "склад", а не товар на складе - это очень грубая ошибка, какой бы суперавтоматизированной система ни была
Про видео соглашусь частично. После записи иногда пользуюсь. Но видео довольно быстро устаревает.
Возможно, скоро будет обыденностью запускать AI по, в т.ч., видео для быстрого поиска и даже для наполнения базы знаний