Скрипты можно генерировать автоматически, для этого есть параметр -script для команды update-database. Со стороны разработчика сначала применяем миграцию вперед с этим флагом для создания файла миграции up. Потом откатываем миграцию на предыдущую с этим флагом - получаем файл скрипта отката миграции.
Если нужно в крипт миграции внедрить скл-код мутации данных, то оный можно написать вызвав метод Sql(string sql) в любом нужном месте как в методе up, так и в методе down.
Могу предположить, что такой подход мог использоваться, но почему-то от него отказались.
И фиг знает какой нужен. Пример выдуманный, на основе того, как реализовано апи iTextSharp работы с пдф - ни описания, ни нормальных именований.
Я не спорю, возможность крутая, но я лучше корявым английским назову метод и добавлю комент. Мне кажется, что проблем от возможности иметь одинаковые сигнатуры с разным именем параметров больше будет
Все, конечно, элегантно пишете, и про дублирование, и про репликацию с транзакциями.. но после прочтения осталалось послевкусие.. сложности что ли
Вот прилетела вам две баги, одна инфраструктурная, одна - бизнесовая. Как вы их отлаживаете?
Как у вас с онбордингом? Сложно ли "среднему" разрабу приступить к работе, разобраться в проекте?
Есть ли какие-то правила ограничения вложенности/наследуемости компонентов? Вангую невозможность разобраться с используемостью (контракта/процессора)-наследника в десятом поколении
Ну, гос клиники явно получили не то, что хотели, с этим соглашусь. Если взять тот же егисз, то максимум, что получили врачи - доступ к глобально общей истории болезни пациента. Но, в основном же, это просто еще одна обязаловка, основанная на бюрократии.
А частникам, если они не ведут стационар, кроме ведения карт, исследований и просмотра отчетов по продажам (если грубо собрать воедино воронку, отчетность по телефонии, и иную отчетность, основанную на продажах) ничего и не надо. И то, многие директора не в курсе что такое воронка
Я тоже читал и плакал с зависти. Порой смотришь на проект и диву даешься, как такое допустили. Но задачи по фичам приоритетнее, поэтому рефакторинг приходится делать мелкими шажками в процессе основных задач (
Не всегда есть возможность запихнуть на прод очередной сервис, в частности, для управления очередями. Ну, возможоость, конечно, есть. Но если, к примеру, ИС представляет из себя надцать сервисов wcf, собирающихся и разворачиваемых вручную, добавлять еще один сервис - лишняя морока тем, кто занимается обновлением
Я вот в геймдеве полный ноль. Но мне было бы интересно почитать больше кишок. Были ли какие-то иные варианты распределения процентов вариативности? Другие способы считать, например, что будет если "кубик" бросить один раз: выпало больше 50ти - хлам, иначе если больше 25ти - обычный предмет, иначе если больше 12ти - редкий и так далее. Почему именно такие числа (простое деление на 2), были ли проведены тесты по балансировке?
Я, может, пропустил, это серия статей по игре или Вы просто вырвали интересную для себя единичную тему? Если это первая статья по игре, было бы полезно начать сначала, а не с лута..
Есть ли какие-то иные способы реализаций инвентаризации и генерации предметов на карте, подкрепленные мировой практикой? Если оные отличаются от Вашей реализации, то в чем отличие, превосходство?..
Ну во-первых, как уже говорили выше, в статье нет ни слова по еф. Ликью можно использовать не только для генерации скл-запросов, но и для работы со списками.
По поводу того, почему в продукте не оказалось категории:
Представьте себе ситуацию, когда вы получаете данные с двух систем. Эти системы знать не знают про друг дружку, но в одной из них в записях хранятся внешние ключи на записи из другой системы. И в таком случае, получив списки данных с обоих систем, нужно их сджонить, чтобы дальше осуществить какие-либо действия. Например, чтобы отобразить, если в действие происходит на клиенте, либо отдать в ответе, если это аггрегатор типа gateway
Take my money!
привет из прошлого) есть перевод следующих частей?)
Ну, перечислить оные, думаю, не составит труда)
Если реализовывать в виде плагинов, то для мвп будет полезным, имхо, реализовать такие источники данных как:
Скл-запросы в одну любую распростаненную субд типа постгрес/мсскл/мускул
Запрос данных из файла одного из распространенных форматов типа json/xml/csv
HTTP(S) запросы с поддержкой одного из распространенных типов ответов типа JSON
Ну а все остальное уже мб сообщество допилит по аналогии
А разные источники данных будут поддерживаться? Мы долгое время сидели на devexpress (c#)
Ну и там есть возможность и хранимки скл использовать в качестве источников данных, и апи-запросы в различных форматах ответов получать.
А так же возможность указывать параметры запросов - пользовательский фильтр данных. Эти параметры пробрасывать в запросы
Скрипты можно генерировать автоматически, для этого есть параметр -script для команды update-database. Со стороны разработчика сначала применяем миграцию вперед с этим флагом для создания файла миграции up. Потом откатываем миграцию на предыдущую с этим флагом - получаем файл скрипта отката миграции.
Если нужно в крипт миграции внедрить скл-код мутации данных, то оный можно написать вызвав метод Sql(string sql) в любом нужном месте как в методе up, так и в методе down.
Могу предположить, что такой подход мог использоваться, но почему-то от него отказались.
А код у вас в апи остается или выносите? Статик или инжект?
На (бонус 4) б ссылку
По go мало информации, надеялся на сравнение. Но за гайд большое благодарю
На столько быстро пролистал, что не увидел рекламы новой книги?
А потом находишь такое:
И фиг знает какой нужен. Пример выдуманный, на основе того, как реализовано апи iTextSharp работы с пдф - ни описания, ни нормальных именований.
Я не спорю, возможность крутая, но я лучше корявым английским назову метод и добавлю комент. Мне кажется, что проблем от возможности иметь одинаковые сигнатуры с разным именем параметров больше будет
Ну и еще вопрос о транзакции. Что у вас стоит за надежностью? Например, если когда отвалится шина?
Все, конечно, элегантно пишете, и про дублирование, и про репликацию с транзакциями.. но после прочтения осталалось послевкусие.. сложности что ли
Вот прилетела вам две баги, одна инфраструктурная, одна - бизнесовая. Как вы их отлаживаете?
Как у вас с онбордингом? Сложно ли "среднему" разрабу приступить к работе, разобраться в проекте?
Есть ли какие-то правила ограничения вложенности/наследуемости компонентов? Вангую невозможность разобраться с используемостью (контракта/процессора)-наследника в десятом поколении
Ну, гос клиники явно получили не то, что хотели, с этим соглашусь. Если взять тот же егисз, то максимум, что получили врачи - доступ к глобально общей истории болезни пациента. Но, в основном же, это просто еще одна обязаловка, основанная на бюрократии.
А частникам, если они не ведут стационар, кроме ведения карт, исследований и просмотра отчетов по продажам (если грубо собрать воедино воронку, отчетность по телефонии, и иную отчетность, основанную на продажах) ничего и не надо. И то, многие директора не в курсе что такое воронка
"Мы" - это врачи гос.клиник или писатели впн-сервиса?
Я тоже читал и плакал с зависти. Порой смотришь на проект и диву даешься, как такое допустили. Но задачи по фичам приоритетнее, поэтому рефакторинг приходится делать мелкими шажками в процессе основных задач (
Очень интересно прочитать в последующих статьях о ЕГИСЗ и его удобстве (как разработчик МИС для частных клиник прошу)
Не всегда есть возможность запихнуть на прод очередной сервис, в частности, для управления очередями. Ну, возможоость, конечно, есть. Но если, к примеру, ИС представляет из себя надцать сервисов wcf, собирающихся и разворачиваемых вручную, добавлять еще один сервис - лишняя морока тем, кто занимается обновлением
Может, альфа третьей версии?)
Я вот в геймдеве полный ноль. Но мне было бы интересно почитать больше кишок. Были ли какие-то иные варианты распределения процентов вариативности? Другие способы считать, например, что будет если "кубик" бросить один раз: выпало больше 50ти - хлам, иначе если больше 25ти - обычный предмет, иначе если больше 12ти - редкий и так далее. Почему именно такие числа (простое деление на 2), были ли проведены тесты по балансировке?
Я, может, пропустил, это серия статей по игре или Вы просто вырвали интересную для себя единичную тему? Если это первая статья по игре, было бы полезно начать сначала, а не с лута..
Есть ли какие-то иные способы реализаций инвентаризации и генерации предметов на карте, подкрепленные мировой практикой? Если оные отличаются от Вашей реализации, то в чем отличие, превосходство?..
Спасибо
Ну во-первых, как уже говорили выше, в статье нет ни слова по еф. Ликью можно использовать не только для генерации скл-запросов, но и для работы со списками.
По поводу того, почему в продукте не оказалось категории:
Представьте себе ситуацию, когда вы получаете данные с двух систем. Эти системы знать не знают про друг дружку, но в одной из них в записях хранятся внешние ключи на записи из другой системы. И в таком случае, получив списки данных с обоих систем, нужно их сджонить, чтобы дальше осуществить какие-либо действия. Например, чтобы отобразить, если в действие происходит на клиенте, либо отдать в ответе, если это аггрегатор типа gateway