Статья классная, но местами зависал. В "1. Cache-Aside (Ленивая загрузка, кеш "в стороне")":
Данные, полученные из БД, кладутся в кеш на будущее. "Вот, кеш, сохрани, может еще пригодится."
Данные - это объект. Они сами никуда не кладутся, их кто-то/что-то кладёт. Судя по контексту, приложение? Но тогда как понимать следующий шаг, если данные уже у приложения?:
Данные отдаются тому, кто их просил
Если отбросить эротические фантазии, кто тут отдаёт данные?
Я, как системный аналитик, поэтому и не утверждаю, а лишь предполагаю. Не вижу проблем генерить ответы, редактируя их по необходимости. В преамбуле ответов отчётливо видна конструкция нечеловека. Ваш ответ выше - одно из исключений
Не понимаю такого интереса к величине выручки. Напродавать на миллиарды, потратив на это десятки миллиардов - тут на Хабре любой сможет. Гораздо интереснее величина дохода. Например, были данные, что тот же ВК в глубочайшем минусе
В моём топе Андрей Мовчан. Нравится его историко-аналитический подход.
Ещё Дмитрий Потапенко и Дмитрий Прокофьев, но для меня там слишком много говорильни и повторов, нет времени уже, скоро перестану слушать
И очень многое - из самых разнообразных именно исторических программ/передач, тут не могу конкретно. История крайне тесно переплетена с экономикой, и наоборот. Поэтому исторические передачи рулят
И неглубоко, и временами уж как-то однобоко. Читал ТГ-канал короткое время в прошлом году, но по этим причинам быстро отписался. YouTube сразу не переварил из-за подачи.
У реальных (практикующих) экономистов и историков (да-да) эти темы интереснее слушать
Не соглашусь только про камеру - по моему опыту, это может сильно отвлекать как ведущих, так и слушателей. Бывают ещё и проблемы с трафиком из-за видео. Но команде виднее
В целом, встреча (созвон) - это ровно такой же рабочий процесс, как и все остальные, содержит все те же самые составляющие (проблема/задача, цель, результат, ресурсы компетенции & исполнения & контроля, входящие/исходящие артефакты...). Поэтому, если ко встрече подходить как к проектированию рабочего процесса, то результат процесса будет качественнее.
Насколько понимаю, невозможно заранее утверждать, что встреча достигнет полного результата. Требуемые ресурсы компетенции для принятия решений могут стать полностью известны только в процессе встречи. Тут только знания, опыт и прочий профессионализм уменьшает степень риска
В самом начале. Непонятно, откуда родились НФТ. Про ФТ всё честно: БТ-ФТ. Вероятно, должно быть (БТ+ФТ)-НФТ
Там же. ФТ-ТК (тест-кейсы). Логичнее (ФТ+UC)-ТК. Потому как ТК это, фактически, UC с результатом из ФТ
функционал реализован, но не соответствует бизнес-требованиям
Всё-таки, "функциональность" звучит приятнее для слуха профессионала :) Главное, тут непонятно, откуда тогда взялась функциональность (мы же всё страссировали при проектировании, верно?). Тут что-то не то или с мыслью, или с формулировкой.
Контроль полноты реализации требований. Позволяет убедиться, что каждое требование было учтено и реализовано в системе. Здесь можно использовать соответствие функциональных и бизнес-требований
Какое отношение имеет соответствие ФТ и БТ, и что использовано в разработке? Надо проверять через все цепочки БТ с результатом (тестами) разработки. ФТ тут промежуточные
Судя по вашей табличке, количество ядер на процессор, наоборот, упало примерно в 2.5 раза. И тактовая частота тоже. Это означает гораздо больше занимаемый объём этой махиной
Заявлено: "как за 8 часов исследовать продуктовый сценарий, нагенерить идей и взяться за макеты". Реально: всё есть, "Заказчик отметил моменты, которые надо доработать" на готовом превью, над которым целая команда работала 3 месяца.
Проблемы на входе? Неизвестны, поэтому зачем и почему всё дальше делает ТС - читатель должен сам догадаться. Я не догадался, ибо нет времени.
Результат? Много разноцветных разномастных элементов, стрелочек на трёх скринах. Я опять туплю, но времени вникать нет. Понятно сформулирована только нерешённая проблема
Крайне скептически отношусь к полезности корпоративных блогов, но этот пост очень содержателен. Правда, не всё нужное увидел (например, структуру доков для управления функциональными требованиями/описаниями). В целом очень здорово. Многие большие команды, которые видел, сильно не дотягивают до уровня этого поста.
Из личного. Год или два назад вакансии аналитиков в Спорт-Мастер запомнились как крайне скучные и формальные. Вероятно, что-то изменилось
О чём и речь. Вы сами зафиксировали, что все варианты оканчиваются одним остановом (завершением процесса) - так соблюдайте же это. Вы понимаете, что один останов и три останова - это, соответственно, одна и три независимые сущности в системе? Вам проще контролировать одну точку или три? Что за содержание между ветвлением и окончанием этого ветвления - вообще не важно, артефакт или суперсложный подпроцесс. Но если вы сейчас, как нарисовали, отпустите на волю этот подпроцес, вы легко и непринуждённо вернётесь назад (плодя логические петли), совершенно забыв про обязательное условие - зафиксировать результат ветвления в собирающем шлюзе.
В реальных системах мы обязаны соблюдать формальную логику, а не "и так же очевидно, чё тут усложнять". Потому что она не для красоты, а для контроля (человеком или движком) начала и завершения всей модели. Поэтому такие примеры, на мой взгляд, вредны.
Тут другие читатели верно заметили про первый пример, где так легко и непринуждённо упущен собирающий шлюз. Это нарушение логики, потенциально ведущее к потерю контроля за процессом.
Решается просто. Что общее у вариантов? Завершение - значит, его оставляем. Собирающий шлюз для соблюдения формальной логики. А что надо, чтобы показать то, что хочет автор? Просто зафиксировть результат процесса, например, доком (артефактом) в каждом варианте. Это гораздо правильнее, потому что в реальной системе комменты на схеме останутся комментами, а артефакт на схеме - это реальный запись в системе с результатом процесса
Сопротивление резистора R2 выше, чем R1, а это ограничивает возможность тока потечь через него
Если дословно верить фразе, то автору удалось придумать альтернативный закон Киргофа - от сопротивлений теперь зависит не сила тока, а его вероятность (возможность). А всего-то не надо вставлять слова-паразиты в технический текст.
Статья классная, но местами зависал.
В "1. Cache-Aside (Ленивая загрузка, кеш "в стороне")":
Данные - это объект. Они сами никуда не кладутся, их кто-то/что-то кладёт. Судя по контексту, приложение? Но тогда как понимать следующий шаг, если данные уже у приложения?:
Если отбросить эротические фантазии, кто тут отдаёт данные?
Я, как системный аналитик, поэтому и не утверждаю, а лишь предполагаю.
Не вижу проблем генерить ответы, редактируя их по необходимости. В преамбуле ответов отчётливо видна конструкция нечеловека. Ваш ответ выше - одно из исключений
Не понимаю такого интереса к величине выручки. Напродавать на миллиарды, потратив на это десятки миллиардов - тут на Хабре любой сможет. Гораздо интереснее величина дохода. Например, были данные, что тот же ВК в глубочайшем минусе
Попробуйте прочитать здесь ответы TC.
Ощущение, что отвечает AI
Не смотрю его на его канале )
В плейлистах нашёл, что я имел ввиду
В моём топе Андрей Мовчан. Нравится его историко-аналитический подход.
Ещё Дмитрий Потапенко и Дмитрий Прокофьев, но для меня там слишком много говорильни и повторов, нет времени уже, скоро перестану слушать
И очень многое - из самых разнообразных именно исторических программ/передач, тут не могу конкретно.
История крайне тесно переплетена с экономикой, и наоборот. Поэтому исторические передачи рулят
Вот, соглашусь.
И неглубоко, и временами уж как-то однобоко. Читал ТГ-канал короткое время в прошлом году, но по этим причинам быстро отписался.
YouTube сразу не переварил из-за подачи.
У реальных (практикующих) экономистов и историков (да-да) эти темы интереснее слушать
Не соглашусь только про камеру - по моему опыту, это может сильно отвлекать как ведущих, так и слушателей. Бывают ещё и проблемы с трафиком из-за видео.
Но команде виднее
В целом, встреча (созвон) - это ровно такой же рабочий процесс, как и все остальные, содержит все те же самые составляющие (проблема/задача, цель, результат, ресурсы компетенции & исполнения & контроля, входящие/исходящие артефакты...). Поэтому, если ко встрече подходить как к проектированию рабочего процесса, то результат процесса будет качественнее.
Насколько понимаю, невозможно заранее утверждать, что встреча достигнет полного результата. Требуемые ресурсы компетенции для принятия решений могут стать полностью известны только в процессе встречи. Тут только знания, опыт и прочий профессионализм уменьшает степень риска
В самом начале. Непонятно, откуда родились НФТ. Про ФТ всё честно: БТ-ФТ.
Вероятно, должно быть (БТ+ФТ)-НФТ
Там же. ФТ-ТК (тест-кейсы). Логичнее (ФТ+UC)-ТК. Потому как ТК это, фактически, UC с результатом из ФТ
Всё-таки, "функциональность" звучит приятнее для слуха профессионала :)
Главное, тут непонятно, откуда тогда взялась функциональность (мы же всё страссировали при проектировании, верно?). Тут что-то не то или с мыслью, или с формулировкой.
Какое отношение имеет соответствие ФТ и БТ, и что использовано в разработке? Надо проверять через все цепочки БТ с результатом (тестами) разработки. ФТ тут промежуточные
Ну там много чего дальше, нет времени, ссори
del
Попробуйте прочитать не только заголовок
Перевод кривой. Динамик не может быть ни BT, ни WiFi, не может иметь аккумулятор и т.п. А вот колонка (акустическая система) - может
Судя по вашей табличке, количество ядер на процессор, наоборот, упало примерно в 2.5 раза. И тактовая частота тоже. Это означает гораздо больше занимаемый объём этой махиной
Заявлено: "как за 8 часов исследовать продуктовый сценарий, нагенерить идей и взяться за макеты".
Реально: всё есть, "Заказчик отметил моменты, которые надо доработать" на готовом превью, над которым целая команда работала 3 месяца.
Проблемы на входе? Неизвестны, поэтому зачем и почему всё дальше делает ТС - читатель должен сам догадаться.
Я не догадался, ибо нет времени.
Результат? Много разноцветных разномастных элементов, стрелочек на трёх скринах.
Я опять туплю, но времени вникать нет. Понятно сформулирована только нерешённая проблема
Увидел
и на этом закончил.
Представляю, какая там каша дальше возможна, если сразу на взлёте чел базово не понимает про объектность/субъектность
Крайне скептически отношусь к полезности корпоративных блогов, но этот пост очень содержателен. Правда, не всё нужное увидел (например, структуру доков для управления функциональными требованиями/описаниями). В целом очень здорово. Многие большие команды, которые видел, сильно не дотягивают до уровня этого поста.
Из личного. Год или два назад вакансии аналитиков в Спорт-Мастер запомнились как крайне скучные и формальные. Вероятно, что-то изменилось
О чём и речь.
Вы сами зафиксировали, что все варианты оканчиваются одним остановом (завершением процесса) - так соблюдайте же это. Вы понимаете, что один останов и три останова - это, соответственно, одна и три независимые сущности в системе? Вам проще контролировать одну точку или три?
Что за содержание между ветвлением и окончанием этого ветвления - вообще не важно, артефакт или суперсложный подпроцесс. Но если вы сейчас, как нарисовали, отпустите на волю этот подпроцес, вы легко и непринуждённо вернётесь назад (плодя логические петли), совершенно забыв про обязательное условие - зафиксировать результат ветвления в собирающем шлюзе.
В реальных системах мы обязаны соблюдать формальную логику, а не "и так же очевидно, чё тут усложнять". Потому что она не для красоты, а для контроля (человеком или движком) начала и завершения всей модели. Поэтому такие примеры, на мой взгляд, вредны.
Тут другие читатели верно заметили про первый пример, где так легко и непринуждённо упущен собирающий шлюз. Это нарушение логики, потенциально ведущее к потерю контроля за процессом.
Решается просто.
Что общее у вариантов? Завершение - значит, его оставляем. Собирающий шлюз для соблюдения формальной логики. А что надо, чтобы показать то, что хочет автор? Просто зафиксировть результат процесса, например, доком (артефактом) в каждом варианте.
Это гораздо правильнее, потому что в реальной системе комменты на схеме останутся комментами, а артефакт на схеме - это реальный запись в системе с результатом процесса
Заголовки 3 и 4 (US и UC) перепутаны местами
Добавлю:
Если дословно верить фразе, то автору удалось придумать альтернативный закон Киргофа - от сопротивлений теперь зависит не сила тока, а его вероятность (возможность).
А всего-то не надо вставлять слова-паразиты в технический текст.