Делал когда-то такое - с таблицами, циклами и условиями вставки. Вот как это выглядело:
Красные - это управляющие коды по разделам, таблицам и др., которые при обработке из документа удалялись, а переменные были просто в квадратных скобках...
По поводу "мы сбросили статистику таблицы и немного подождали" - иногда таким образом можно удалить нужные индексы, которые используются для отчетов, которые запускаются раз в месяц или еще реже.
У нас однажды так сломался отчет - вместо минут начал считаться десятки часов. И естественно - "никто ничего не делал". Потратили несколько дней, чтобы починить и только потом выяснилось, что "все таки делали, но уже месяц назад, а это уже как-бы не считается".
Мне кажется, подобные гайды было бы очень полезно сопровождать примером проекта, в котором было бы показано практическое применение того, что написано выше.
У нас был проект, где мы с подачи специалистов IBM использовали ленточное хранилище от IBM для уровня отложенного доступа - от него требовалась загрузка по требованию (это когда данные уехали на ленту и были стерты из БД, но вдруг понадобились опять и их нужно восстановить с ленточного хранилища в БД) - ну и намучились же мы с ним!
Нигде не написано, но лента имеет очень ограниченный ресурс по количеству перемоток, который по факту выбирается за считанные месяцы. А потом ленты нужно менять или начинать оплакивать погибшие данные...
Бизнес-аналитик описывает бизнес-процессы, регламентирует и формализует работу предприятия на конкретном участке. Описывает функции между процессами.
Как-то это очень однобокая формулировка...
Бизнес-аналитик собирает и описывает требования. Точка!
Например, нужно разработать UI, формализовать бизнес требование заказчика, описанное в свободном стиле вроде "Хочу, чтобы ..." в виде списка именно требований, которые полностью опишут все нюансы того, что хочет заказчик, выполнить согласование бизнес требований от разных источников и многое многое другое. Все это работа с требованиями, а процессов при этом может и не быть вовсе...
В статье упущена скорость генерации активов (золото, предметы) - а ведь это один из базовых показателей финансовой системы. В разных играх он отыгрывается по разному (как шанс успешного выпадения/создания, через выносливость игрока при крафте и т.д.). Т.е. как любой урон выражают в DPS, так любую финансовую систему нужно смотреть в разрезе золото/минуту.
При этом этот график стартует от начала координат и растет в зависимости от уровня игрока/профы/монстра. Редкость и уникальность предметов/монстров образует некое поле точек снизу и сверху от линии графика. На сколько резко растет золото/минуту от уровня - это вопрос баланса.
Впрочем, обо всем этом думать еще рано...
Вы писали про спекулянтов и почти попали в точку. Один из первых вопросов, на который вы должны для себя ответить "Кто и как зарабатывает на игровой валюте в моей игре?". Это, если хотите - бизнес требования от тех, для кого вы собственно все это затеваете. Вот когда вы полностью опишите эти требования, то это станет фундаментом, на котором вы начнете создавать свою систему.
И вопрос - более крупные объекты, включающие в себя N травинок с различным рисунком их роста не будут занимать меньше памяти? По идее таким подходом "instance count" можно уменьшить на 1-2 порядка...
Слишком долго все целенаправленно разваливали. Сейчас можно сесть и написать план из 10 пунктов. Потом посмотреть на каждый пункт и добавить к нему 10 подпунктов. А потом еще и еще...
И где-нибудь на 10 итерации наконец будут пункты про образование, которые нужно выполнить сейчас, чтобы получить эффект через 10 лет. А говорить об успехе реформ можно будет только через 20+.
А еще - достижимость результата зависит не только от реформирования ИТ. Текущий уровень коррупции похоронит любые усилия в этом направлении. Но коррупция это не все. Нужно меняться во всех областях и меняться сильнее, чем сейчас готовы многие из тех, кто владеет заводами, пароходами или принимает решения от государства...
Как-то мухи с котлетами смешались - нотации и средства.
Это все равно, что написать - а я вот в WORD документы делаю и у меня в документах есть текст, таблицы и схемы!
Вы говорите об UML, но приводите из него только диаграмму последовательностей. Я понимаю, что вы имели ввиду, что из всего разнообразия UML в основном используете именно эту диаграмму. Но в тексте этого нет.
BPMN - приведенная схема прекрасный пример того, как не нужно делать. Divide et impera - принцип для людей, но для процессов он тоже отлично подходит. Если на диаграмме больше 10 задач - выделяйте часть в отдельный подпроцесс. И понимать и сопровождать такое описание будет на порядок проще.
Confluence - это инструмент. Нашли другой инструмент, который больше подходит именно вам - это просто отлично. Либо учитесь использовать Confluence, но не требуйте от него, чтобы он наладил вам рабочие процессы.
Если бы кто-то это утянул себе на прод и словил убытки, этот школьник мог бы получить много нового жизненного опыта. Но пронесло в этот раз...
У меня лицензионная Windows, однако скачать с официального сайта дистрибутив я не смог. В результате скачал официальную реплику с торрента...
Так что вариант "Никогда, у меня есть лиц.Windows и мне не нужна пиратка" при наличии лицензии не всегда работает ...
Делал когда-то такое - с таблицами, циклами и условиями вставки. Вот как это выглядело:
Красные - это управляющие коды по разделам, таблицам и др., которые при обработке из документа удалялись, а переменные были просто в квадратных скобках...
По поводу "мы сбросили статистику таблицы и немного подождали" - иногда таким образом можно удалить нужные индексы, которые используются для отчетов, которые запускаются раз в месяц или еще реже.
У нас однажды так сломался отчет - вместо минут начал считаться десятки часов. И естественно - "никто ничего не делал". Потратили несколько дней, чтобы починить и только потом выяснилось, что "все таки делали, но уже месяц назад, а это уже как-бы не считается".
Мне кажется, подобные гайды было бы очень полезно сопровождать примером проекта, в котором было бы показано практическое применение того, что написано выше.
Красивое!
Допиши тогда в список Apache NiFi и Talend Open Studio. Это ETL конструкторы, на которых можно все, что угодно накрутить...
У нас был проект, где мы с подачи специалистов IBM использовали ленточное хранилище от IBM для уровня отложенного доступа - от него требовалась загрузка по требованию (это когда данные уехали на ленту и были стерты из БД, но вдруг понадобились опять и их нужно восстановить с ленточного хранилища в БД) - ну и намучились же мы с ним!
Нигде не написано, но лента имеет очень ограниченный ресурс по количеству перемоток, который по факту выбирается за считанные месяцы. А потом ленты нужно менять или начинать оплакивать погибшие данные...
Поднимать цены конкуренция не позволит.
Обычно в этом случае производитель ищет новые рынки сбыта, оптимизирует тех процесс или меняет производство самого товара.
Если ничего это не помогает - сливается (укрупняется) или исчезает..
"срыв сроков обычно не критичен для бизнеса"
Как раз обычно критичен, ибо срыв сроков = дополнительные затраты а денег обычно в обрез!
"Собирать логи (только для УЗ2)." - по факту безопасники Заказчика требуют всегда, если есть перс данные.
И да - при наличии перс данных логов у нас нет - вместо них у нас события безопасности :)
Как-то это очень однобокая формулировка...
Бизнес-аналитик собирает и описывает требования. Точка!
Например, нужно разработать UI, формализовать бизнес требование заказчика, описанное в свободном стиле вроде "Хочу, чтобы ..." в виде списка именно требований, которые полностью опишут все нюансы того, что хочет заказчик, выполнить согласование бизнес требований от разных источников и многое многое другое. Все это работа с требованиями, а процессов при этом может и не быть вовсе...
В статье упущена скорость генерации активов (золото, предметы) - а ведь это один из базовых показателей финансовой системы. В разных играх он отыгрывается по разному (как шанс успешного выпадения/создания, через выносливость игрока при крафте и т.д.). Т.е. как любой урон выражают в DPS, так любую финансовую систему нужно смотреть в разрезе золото/минуту.
При этом этот график стартует от начала координат и растет в зависимости от уровня игрока/профы/монстра. Редкость и уникальность предметов/монстров образует некое поле точек снизу и сверху от линии графика. На сколько резко растет золото/минуту от уровня - это вопрос баланса.
Впрочем, обо всем этом думать еще рано...
Вы писали про спекулянтов и почти попали в точку. Один из первых вопросов, на который вы должны для себя ответить "Кто и как зарабатывает на игровой валюте в моей игре?". Это, если хотите - бизнес требования от тех, для кого вы собственно все это затеваете. Вот когда вы полностью опишите эти требования, то это станет фундаментом, на котором вы начнете создавать свою систему.
Мне в UNIGINE понравилось, как траву сделали: https://youtu.be/HbiCY3YgAII.
И вопрос - более крупные объекты, включающие в себя N травинок с различным рисунком их роста не будут занимать меньше памяти? По идее таким подходом "instance count" можно уменьшить на 1-2 порядка...
Слишком долго все целенаправленно разваливали. Сейчас можно сесть и написать план из 10 пунктов. Потом посмотреть на каждый пункт и добавить к нему 10 подпунктов. А потом еще и еще...
И где-нибудь на 10 итерации наконец будут пункты про образование, которые нужно выполнить сейчас, чтобы получить эффект через 10 лет. А говорить об успехе реформ можно будет только через 20+.
А еще - достижимость результата зависит не только от реформирования ИТ. Текущий уровень коррупции похоронит любые усилия в этом направлении. Но коррупция это не все. Нужно меняться во всех областях и меняться сильнее, чем сейчас готовы многие из тех, кто владеет заводами, пароходами или принимает решения от государства...
Самое важное отличие от ФИАС - ГАР лучше сопровождается.
Справочник реализовывают один раз а с ошибками адресов мучаются годами.
Как-то мухи с котлетами смешались - нотации и средства.
Это все равно, что написать - а я вот в WORD документы делаю и у меня в документах есть текст, таблицы и схемы!
Вы говорите об UML, но приводите из него только диаграмму последовательностей. Я понимаю, что вы имели ввиду, что из всего разнообразия UML в основном используете именно эту диаграмму. Но в тексте этого нет.
BPMN - приведенная схема прекрасный пример того, как не нужно делать. Divide et impera - принцип для людей, но для процессов он тоже отлично подходит. Если на диаграмме больше 10 задач - выделяйте часть в отдельный подпроцесс. И понимать и сопровождать такое описание будет на порядок проще.
Confluence - это инструмент. Нашли другой инструмент, который больше подходит именно вам - это просто отлично. Либо учитесь использовать Confluence, но не требуйте от него, чтобы он наладил вам рабочие процессы.
Я наверно очень старомоден - терпеть не могу анимацию! Даже на развлекательных сайтах.
Последние несколько лет из Москвы и подмосковья выжимали небольшие фирмы, у которых цены были ниже и "китам" приходилось это учитывать.
В 2021 году этот процесс завершился, теперь рынок такси монополизирован и все пожинают результаты: монополисты - барыши, жители - цены на поездки.
Интересно, скорость очистки грунта от тяжелых металлов с помощью бактерий с последующим разделением не быстрее?
Если люди будут жить на луне и дальше, то почвы понадобится много, а растения делают это слишком медленно...