В хендбрейке те же опции, что и в статье, только через ГУИ.
Ну, у автора же посыл, что к чёрту все эти удобные штуки, побежали в командную строку, там всё гораздо интереснее
При CRF-кодировании ограничение битрейта нужно для того чтобы новая порция данных успевала считаться с диска или загрузиться по сети, а также учитывается размер буфера на плеере
Мы же говорим про кодирование, а не про воспроизведение? Каким образом я, перекодируя видео, могу предвидеть, какой там буфер у заранее неизвестного плеера и какие там скорости будут у совершенно мне неведомого носителя?
В общем, я впервые слышу, что при выборе CRF надо учитывать параметры носителя и плеера. Возможно, для специальных случаев, но явно не "для дома, для семьи". Не могу представить, чтобы HDD даже 10-15 летней давности (SATA-II, правильно помню?) не тянули полноценный блюрей, не говоря уже о пожатых видео
указание большего или меньшего значения CRF в большей степени зависит от скорости вашего накопителя, нежели от процессора
Какое отношение уровень качества видео имеет к скорости накопителя? Вообще никакого. В худшем случае, от скорости накопителя будет зависеть скорость кодирования, но никак не CRF.
В целом, статья совсем не убедила перейти с Handbrake или StaxRip на предложенную командную строку
Пример Use Case содержит ряд грехов по версии всех религий, кроме ленивой.
Актор висит в вакууме, выбрает товары в вакууме и т.п. Если свою систему не причисляете к акторам (а зря), то надо указать, с чем взаимодействует один этот актор.
Система, по-видимому, обладает телепатией, раз знает, есть товар на складе или нет. Надо анализировать наличие товара в системе с признаком "склад", а не товар на складе - это очень грубая ошибка, какой бы суперавтоматизированной система ни была
Полностью солидарен с @Cordekk Если не зафиксировать (для всех участников!) мемо в самое короткое время после окончания встречи, то какие-то детали потеряются. Если вообще не зафиксировать - потеряется значимое инфо, причём у всех сторон. Сплошь и рядом вижу это
Не советую новичку это читать. Какая-то дикая смесь всего со всем, потом потратите гораздо больше времени на исправление своих знаний.
Прямо с первой же картинки. Попробуйте определить, кто на ком там стоял - компоненты системы чудесным образом взаимодействуют то ли с архитектурным стилем, то ли с API в вакууме (сервер-то отдельно нарисован).
Схемы "неоднородных", прости господи, фронта и бэка просто чудесны, но тут уж сами, мне дальше лень
Допустим, что наша цель в 2024 году — это увеличить лояльность.
Хотите сделаю 99% всех клиентов абсолютно лояльными? Предоставлю им бесплатные полёты! Зачем какие-то розетки придумывать? С точки достижения цели я гораздо вас эффективнее - берёте на работу?
Это к тому, что явно с целью что-то не то. Толсто намекаю - есть цель, а есть способ достижения цели, и есть средства для каждого способа
Собственно, к объявленной теме - как обеспечить (= формировать) качественный бэклог - статья имеет весьма посредственное отношение. Очередной (возможно, полезный) рассказ о том, как выстроены рабочие процессы разработки глазами системного аналитика
Не есть гуд, если в команде бэклог формирует системный аналитик при наличии других ролей, близких к бизнесу. Что и видно по статье, прямо с первых строчек, что аналитик - пуп разработки
Таким образом, монолит — это не что иное, как строго одна единица развёртывания
Хотелось бы добавить, что при этом допускается изменение монолита отдельно по модулям, т.е. деплой отдельных модулей в рамках уже развёрнутого монолита (так понял рассказы разрабов).
По итогам статьи не понял, насколько хорошо сработал (срабатывает) эта модель оценки? Вы как-то оценивали попадание, разброс оценок и реальность?
В целом, к сожалению, модель применима исключительно к продуктовой команде, которая много лет сидит на продукте и может многими итерациями подгонять свои коэффициенты
Суть статьи даже не обсуждаю, абсолютно верно. Но проблема на другом уровне - уровне организации проекта/продукта. Если процессы построены так, что вопросы системного аналитика игнорятся, потому что ответственные за это роли - БА, продакт, роли заказчика - уже приняли решение, и приняли без вас (у них сроки/планы/бюджеты и, не дай бог, завышенная оценка своих решений), то вся эта красота про критическое мышление лопается.
Было пару раз недавно при прохождении собесов, на раунде уже с "главным" аналитиком. Звучало примерно так: "наш БА утверждает требования, а дальше твоя задача это реализовать. Если у тебя вопросы, то это твоя проблема - наш БА очень занят, и мы ценим время заказчика". Весьма уважаемые компании. После таких собесов ещё по полчаса приходил в себя :). К сожалению, бывают проблемы и внутри команды. Справедливости ради, столкнулся лишь на предпоследнем проекте - когда на твои вопросы твой же коллега-аналитик(!) в команде отвечал, что "вопросы бесполезные" и со спокойной совестью сливался в туман. О каком тут критическом мышлении можно говорить?
Спасибо, довольно много полезных практических подробностей - чужие грабли и результаты всегда очень интересны. Мне не хватило графического представления как встроена ИТ-безопасность в общий архитектурный процесс. В общем-то, понятно, что любой кусок архитектуры, как и безопасность, сам по себе не должен жить.
Недавно посмотрел про архитектуру Спорт-мастера https://www.youtube.com/watch?v=Ao7xqs_oX9s , там стройно и в целом понятно показана логика работы архитекторов. Вот в примерно в таком бы виде, где и как ваша ИБ-архитектура живёт, было бы супер
Спасибо за статью, но, если честно, ничего не понял, что сделано. У меня гораздо ниже квалификация, поэтому искренне пытался понять заложенные смыслы статьи.
Тяжело сформулировано "В процессе рассмотрения одного из вариантов решения...", из которого, после 3-го прочтения, вроде бы понял, что не будет перехода на монорепозиторий. Однако в "В итоге..." уже говорится про монорепозиторий.
"В итоге..." напомнило "делай хорошо, не делай плохо", но что конкретно сделано?: 1) доработали Bitbucket в чём? 2) доп. ресурсы какие и для чего? 3) метрики чего и какие? 4) а если бы разработали не особый "ноу-хау", то что? В чём "ноу-хау" состоит, в чём его (неизвестного никому из непосвящённых) особенность? Какие особенности проектов здесь играют роль? Иначе всю статью можно было бы уместить в 3 предложения: У нас проблемы (большой список). Мы придумали особый ноу-хау. Мы довольны, все свободны. 5) внедрили Yarn 4 и CODEOWNERS для чего? Какие проблемы закрыли каждым из этих слов? 6) ужесточили релизный цикл по каким его характеристикам? 7) в чём заключается доработка производственного процесса? 8) в какой части, что конкретно улучшили в онбординге?
Но есть проблемы таких простых примеров. И я не понимаю, как аналитики их решают. Если вернуться в реальность, то покупатель обычно платит или в технологическом окне баристы, или уже по получению кофе. Потому что если вы хотите, чтобы в следующий раз покупатель пришёл к вам, то вы сначала запустите небыстрый процесс приготовления кофе, а не процесс оплаты. Теперь самое весёлое - попробуйте показать эти три альтернативные оплаты на диаграмме. Ну хотя бы две. Я даже не прошу быть ещё ближе к реальности, когда обычно есть ещё участник в виде отдельного (мобильного) платёжного терминала, который вынесен к покупателю. Вот за это не люблю Sequence. Читабельно только для самых простых сценариев, и не дай бог там альтернативы, затрагивающие процесс всего сценарий. Про негативные сценарии тут вообще лучше забыть
Мне вот интересно, а кто-нибудь вообще вчитывался в эту статью?
Это общее правило: с событием не связывается ни один элемент, кроме функции
Чуть дальше идёт схема, где с событием связан логический элемент, а не функция. Не понял.
правило, которому нужно придерживаться на 100%: логические решения могут приниматься только при выполнении функции
Дальше в тексте есть пример применения логического решения после события, а не функции. Не понял.
Логический элемент «И».Когда для выполнения функции требуется одновременное выполнение нескольких событий:
А если события выполняются не одновременно, а последовательно? (Подсказка - надо рассматривать не время, а факт выполнения. Аналитик не должен такие понятия путать) Очень интересные формулировки логики в статье, не находите?
Логический элемент «ИЛИ».Соединение элементов, если одно из событий может вызвать выполнение функции:
А может и не вызвать, что ли?
В общем, устал я это читать. Думал быстренько понять про EPC, а тут такое...
Спасибо за подробную статью. Как вариант подступиться к задаче, очень даже хорош.
Продуктовая аналитика. 1. События
Более традиционно принято это показывать в виде схемы (бизнес-)процессов на этапе формирования ФТ. Помогает и ФТ точнее формулировать, и, если надо, то показывать логику появления событий, их результат. Метрики - это уже одно из применений схемы, а не причина появления такой схемы. Читать события в табличке без из визуализации я б не осилил :)
Статья достаточно большая, мне не хватило Содержания. Неудобно искать
Ну, у автора же посыл, что к чёрту все эти удобные штуки, побежали в командную строку, там всё гораздо интереснее
Мы же говорим про кодирование, а не про воспроизведение?
Каким образом я, перекодируя видео, могу предвидеть, какой там буфер у заранее неизвестного плеера и какие там скорости будут у совершенно мне неведомого носителя?
В общем, я впервые слышу, что при выборе CRF надо учитывать параметры носителя и плеера. Возможно, для специальных случаев, но явно не "для дома, для семьи". Не могу представить, чтобы HDD даже 10-15 летней давности (SATA-II, правильно помню?) не тянули полноценный блюрей, не говоря уже о пожатых видео
Какое отношение уровень качества видео имеет к скорости накопителя? Вообще никакого.
В худшем случае, от скорости накопителя будет зависеть скорость кодирования, но никак не CRF.
В целом, статья совсем не убедила перейти с Handbrake или StaxRip на предложенную командную строку
Пример Use Case содержит ряд грехов по версии всех религий, кроме ленивой.
Актор висит в вакууме, выбрает товары в вакууме и т.п.
Если свою систему не причисляете к акторам (а зря), то надо указать, с чем взаимодействует один этот актор.
Система, по-видимому, обладает телепатией, раз знает, есть товар на складе или нет. Надо анализировать наличие товара в системе с признаком "склад", а не товар на складе - это очень грубая ошибка, какой бы суперавтоматизированной система ни была
Про видео соглашусь частично. После записи иногда пользуюсь. Но видео довольно быстро устаревает.
Возможно, скоро будет обыденностью запускать AI по, в т.ч., видео для быстрого поиска и даже для наполнения базы знаний
Полностью солидарен с @Cordekk
Если не зафиксировать (для всех участников!) мемо в самое короткое время после окончания встречи, то какие-то детали потеряются. Если вообще не зафиксировать - потеряется значимое инфо, причём у всех сторон.
Сплошь и рядом вижу это
надеюсь, коммент не требуется
Не советую новичку это читать. Какая-то дикая смесь всего со всем, потом потратите гораздо больше времени на исправление своих знаний.
Прямо с первой же картинки. Попробуйте определить, кто на ком там стоял - компоненты системы чудесным образом взаимодействуют то ли с архитектурным стилем, то ли с API в вакууме (сервер-то отдельно нарисован).
Схемы "неоднородных", прости господи, фронта и бэка просто чудесны, но тут уж сами, мне дальше лень
Дочитал только до слов
Хотите сделаю 99% всех клиентов абсолютно лояльными? Предоставлю им бесплатные полёты! Зачем какие-то розетки придумывать? С точки достижения цели я гораздо вас эффективнее - берёте на работу?
Это к тому, что явно с целью что-то не то. Толсто намекаю - есть цель, а есть способ достижения цели, и есть средства для каждого способа
Собственно, к объявленной теме - как обеспечить (= формировать) качественный бэклог - статья имеет весьма посредственное отношение. Очередной (возможно, полезный) рассказ о том, как выстроены рабочие процессы разработки глазами системного аналитика
Не есть гуд, если в команде бэклог формирует системный аналитик при наличии других ролей, близких к бизнесу. Что и видно по статье, прямо с первых строчек, что аналитик - пуп разработки
Хотелось бы добавить, что при этом допускается изменение монолита отдельно по модулям, т.е. деплой отдельных модулей в рамках уже развёрнутого монолита (так понял рассказы разрабов).
Спасибо за коммент.
Просто обратил внимания на противоречия, а здесь как раз с логикой надо быть очень аккуратным.
Попал сюда по выдаче поисковика, чтобы перед собесом пробежаться по верхам, что такое EPC, которое было в требованиях. Ну, вот результат.
За ссылку на сравнение спасибо, посмотрю
По итогам статьи не понял, насколько хорошо сработал (срабатывает) эта модель оценки? Вы как-то оценивали попадание, разброс оценок и реальность?
В целом, к сожалению, модель применима исключительно к продуктовой команде, которая много лет сидит на продукте и может многими итерациями подгонять свои коэффициенты
Суть статьи даже не обсуждаю, абсолютно верно.
Но проблема на другом уровне - уровне организации проекта/продукта. Если процессы построены так, что вопросы системного аналитика игнорятся, потому что ответственные за это роли - БА, продакт, роли заказчика - уже приняли решение, и приняли без вас (у них сроки/планы/бюджеты и, не дай бог, завышенная оценка своих решений), то вся эта красота про критическое мышление лопается.
Было пару раз недавно при прохождении собесов, на раунде уже с "главным" аналитиком. Звучало примерно так: "наш БА утверждает требования, а дальше твоя задача это реализовать. Если у тебя вопросы, то это твоя проблема - наш БА очень занят, и мы ценим время заказчика". Весьма уважаемые компании. После таких собесов ещё по полчаса приходил в себя :).
К сожалению, бывают проблемы и внутри команды. Справедливости ради, столкнулся лишь на предпоследнем проекте - когда на твои вопросы твой же коллега-аналитик(!) в команде отвечал, что "вопросы бесполезные" и со спокойной совестью сливался в туман.
О каком тут критическом мышлении можно говорить?
Спасибо, довольно много полезных практических подробностей - чужие грабли и результаты всегда очень интересны.
Мне не хватило графического представления как встроена ИТ-безопасность в общий архитектурный процесс. В общем-то, понятно, что любой кусок архитектуры, как и безопасность, сам по себе не должен жить.
Недавно посмотрел про архитектуру Спорт-мастера https://www.youtube.com/watch?v=Ao7xqs_oX9s , там стройно и в целом понятно показана логика работы архитекторов. Вот в примерно в таком бы виде, где и как ваша ИБ-архитектура живёт, было бы супер
Из статьи не понял, а лезть в стандарт лень - E.123 допускает оба варианта?:
(в начале статьи, и почему-то 9 цифр без кода страны)
(в середине статьи)
Спасибо за статью, но, если честно, ничего не понял, что сделано. У меня гораздо ниже квалификация, поэтому искренне пытался понять заложенные смыслы статьи.
Тяжело сформулировано "В процессе рассмотрения одного из вариантов решения...", из которого, после 3-го прочтения, вроде бы понял, что не будет перехода на монорепозиторий. Однако в "В итоге..." уже говорится про монорепозиторий.
"В итоге..." напомнило "делай хорошо, не делай плохо", но что конкретно сделано?:
1) доработали Bitbucket в чём?
2) доп. ресурсы какие и для чего?
3) метрики чего и какие?
4) а если бы разработали не особый "ноу-хау", то что? В чём "ноу-хау" состоит, в чём его (неизвестного никому из непосвящённых) особенность? Какие особенности проектов здесь играют роль?
Иначе всю статью можно было бы уместить в 3 предложения: У нас проблемы (большой список). Мы придумали особый ноу-хау. Мы довольны, все свободны.
5) внедрили Yarn 4 и CODEOWNERS для чего? Какие проблемы закрыли каждым из этих слов?
6) ужесточили релизный цикл по каким его характеристикам?
7) в чём заключается доработка производственного процесса?
8) в какой части, что конкретно улучшили в онбординге?
Получается, у вас ограничения не являются частью требований и живут отдельной жизнью? Что тогда включает в себя "требование"?
Спасибо, показано понятно и доступно.
Но есть проблемы таких простых примеров. И я не понимаю, как аналитики их решают.
Если вернуться в реальность, то покупатель обычно платит или в технологическом окне баристы, или уже по получению кофе. Потому что если вы хотите, чтобы в следующий раз покупатель пришёл к вам, то вы сначала запустите небыстрый процесс приготовления кофе, а не процесс оплаты.
Теперь самое весёлое - попробуйте показать эти три альтернативные оплаты на диаграмме. Ну хотя бы две. Я даже не прошу быть ещё ближе к реальности, когда обычно есть ещё участник в виде отдельного (мобильного) платёжного терминала, который вынесен к покупателю.
Вот за это не люблю Sequence. Читабельно только для самых простых сценариев, и не дай бог там альтернативы, затрагивающие процесс всего сценарий. Про негативные сценарии тут вообще лучше забыть
Мне вот интересно, а кто-нибудь вообще вчитывался в эту статью?
Чуть дальше идёт схема, где с событием связан логический элемент, а не функция.
Не понял.
Дальше в тексте есть пример применения логического решения после события, а не функции.
Не понял.
А если события выполняются не одновременно, а последовательно? (Подсказка - надо рассматривать не время, а факт выполнения. Аналитик не должен такие понятия путать)
Очень интересные формулировки логики в статье, не находите?
А может и не вызвать, что ли?
В общем, устал я это читать. Думал быстренько понять про EPC, а тут такое...
Спасибо за подробную статью. Как вариант подступиться к задаче, очень даже хорош.
Более традиционно принято это показывать в виде схемы (бизнес-)процессов на этапе формирования ФТ. Помогает и ФТ точнее формулировать, и, если надо, то показывать логику появления событий, их результат. Метрики - это уже одно из применений схемы, а не причина появления такой схемы.
Читать события в табличке без из визуализации я б не осилил :)
Статья достаточно большая, мне не хватило Содержания. Неудобно искать