На счёт Белоруссии — там всё возможно. Если бы мне бы сказали что 1С не подходит и нужно что-то еще, то IsFusion безусловно мной бы рассматривался как один из вариантов.
Почему такая любоффь к 1С? Да нет никакой любви — банально 99% людей, которых вы принимаете на работу с ней умеют работать.
Есть опыт over 10 лет по .NET. Есть опыт взаимодействия с 1С, SAP и ресторанными системами iiko и rKeeper. Есть вещи которые банально не делаются в рамках бухгалтерских программ, бухгалтеры страдают но ничего сами не попросят. Есть вещи которые связаны с передачей данных между системами и их верификаций.
Чем сильнее конфигурация 1С отличается от стандартной — тем больше с ней возни и проблем.
В интересах конечного заказчика чтобы решение работало просто эффективно
1С это для бухгалтера. Если нужна какая-то другая автоматизация нужно отдельное специализированное решение адаптированное под предметную область. По аналогии как Додо делало для своих пиццерий.
Это решение либо покупается, либо пилится внутри компании усилиями 3-4 разработчиков на каком-то мейнстримовом языке вроде java/c#/go
Это как раз событие и факт достижения информации о событии до наблюдателя с Земли. И MRO на орбите Марса и DSN на Земле фиксируют одно и то же событие. Когда событие одно — вообще разговоры об одновременности бессмысленны.
И где в рассматриваемой ситуации эта локальная одновременность есть? У нас что два ровера садилось? Еще раз. У нас всего одно событие — посадка ровера. Одновременность это свойство двух событий. У нас какую систему отсчёта ни возьми — никакой одновременности нет :-D
У нас две системы отсчёта и в каждой из них по наблюдателю, а не одна.
Согласно специальной теории относительности Эйнштейна, невозможно сказать в абсолютном смысле, что два разных события происходят одновременно, если эти события разделены в пространстве. Если одна система отсчета назначает одно и то же время двум событиям, находящимся в разных точках пространства, то система отсчета, которая движется относительно первой, назначает разные времена для этих двух событий (единственное исключение — когда движение точно перпендикулярно линии, соединяющей точки этих событий).
В этой системе у нас два наблюдателя — MRO и DSN. Информация между этими двумя наблюдателями передается со скоростью света. Наблюдатель MRO видит ситуацию с задержкой которой можно пренебречь. Наблюдатель на DSN видит ситуацию с задержкой в несколько минут, т.к. между MRO и DSN есть большое расстояние которым в этом случае нельзя пренебречь.
Понятие момент времени вводится для конкретного наблюдателя и конкретной системы отсчёта. Поэтому в таких условиях вообще невозможно говорить об одновременности событий, т.к. событие всего одно — посадка ровера. Факт получения информации об этом событии идёт от Марса до Земли несколько минут. Задержка обусловлена тремя факторами: временем сжатия фото-видео информации (там процессор не быстрый — 133МГц), кодированием информации для передачи и собственно её передачей. И в такой конфигурации может оказаться что сжатие и кодирование даёт существенную добавку к времени передачи фото-видео инфорации.
Автор статьи же намерено троллит людей двумя факторами:
1. Тем что большинство людей не в курсе что в СТО понятие одновременности определено для пары (систем отсчёта + наблюдатель с часами)
2. Что намеренно уводит беседу в область теоретической физики не давая людям вспомнить о суровой правде жизни — радиационно-защищенные процессоры достаточно медленные + об необходимости помехозащищенной передачи данных (гуглите про Вояджер и коды Рида-Соломона)
Да, и как раз поиск этого «темного потока» — отдельный вид шаманизма. В реликтовом фоне есть достаточно большие флуктуации которые могут или не могут быть им :-D
Кто-то из физиков высказывал интересную версию что на высоких частотах вроде как можно заметить эхо от сжатия предыдущего цикла вселенной если таковой был.
Сейчас это всё можно сделать в виде docker файла. Более того если еще и docker-compose сделать то можно добавить этап прогона интеграционных тестов (если поднять еще базу, redis,rabbit и всё остальное что нужно).
На билдовой машине при этом нужен только docker
1. Там же важнее переиспользование структур SocketAsyncEventArgs — что дает меньший расход памяти и уменьшает нагрузку на GC.
2. На уровне .NET Standard 2.0 код нормально шарился между платформами. В крайнем случае можно было настроить multitargeting на netcoreapp2.1, netstandard2.0 и net47. А на .NET Core 3 и 3.1 уже даже WPF заработал.
P.S. Вообще интересно даже что вы там такое использовали, что только .NET 5 нормально стал поддерживать?
У меня возникло два вопроса?
1. Почему код сокетов не был переписан на асинхронные сокеты (это не те что async/await, а те что SocketAsyncEventArgs)?
2. Почему не был осуществлен переход на Core 2.x. Я в одном из проектов с Mono под ARM благополучно перешел на core под ARM, а уж 3.1 там поддерживал любые изыски.
При развертывании в Kubernates, вам нужен init-контейнер, который приготавливает базу.
При развертывании локально вам нужно чтоб миграции выполнились при старте сервиса. Не всегда используется EF, я, например, использую пару NHibernate и Dapper в зависимости от потребностей
Что касается кодов ошибок, таких кодов не так много.
200 — стандартный ответ
204 — null (реализовано .NET)
На все остальные кидается Exception, который выставляет код ошибки.
Я лично за подход 200 — возвращается всегда когда API правильно отработало запрос, 500 — когда произошла ошибка. Ведь сервисы еще и мониторить надо
Автомэппер тоже отдельное зло. Я помню как сделал protected set в просто set и Mapster сломался. Учитывая что правка была оценена в 1 час, пришлось сделать public метод, который эту логику реализовывает. Поэтому автомепперы это тоже зло.
Более того часто люди не понимают как это работает — в итоге получаем что у нас есть три enum в разных проектах, которые в друг друга мапятся вместо одно enum.
А задачи по добавлению одного поля в ответ отнимают половину рабочего дня. А если там еще интеграционные тесты на каком-нибудь питоне, то задача по добавлению одного поля может и за 2 дня в мастер не вмерджиться.
Кодогенерацию еще и запускать надо. В новом .NET 5 она уже нормальная станет
В любой компании есть человек, который любит придумывать такие абстракции над абстракциями и еще обижается когда их мало кто использует.
Архитектура проекта должна быть такова, чтобы позволять делать вещи удобно и с минимальными усилиями, при этом оставляя проект тестируемым.
Если взять C# то тут:
1. БД должна быть полностью описана миграциями (FluentMigrator)
2. Уровень доступа к БД должен быть покрыт компонентными тестами которые выполняются в Docker (поднимается минимальная рабочая инфраструктура для сервиса)
3. Должны быть интеграционные тесты выполняющие определенные сценарии, также исполняемые в Docker, при этом тесты должны быть внутри этого же решения.
4. Для каждого контроллера делать фасад. Никакой логики в контроллере. В простейшем случае фасад же и будет репозиторием.
5. Никогда не закладывать в начале создания сервиса overhead на репозитории, внутренние сервисы и прочее когда в них нет надобности. В 99% случаев микросервисов достаточно контроллера, фасада и уровня ORM.
6. Давать именам осмысленные названия чтобы проект не состоял из кучи бессмысленных producer,consumer,context и прочего вырвиглаза который не нужно инжектить. Его можно просто создать в том сервисе, который логически за всё это отвечает, а не в инициализации контейнера.
7. Шаблон репозиторий на высокой нагрузке приводит к тому, что код на нём сложно оптимизировать. Например, в процессе оптимизации просто приходится напрямую в базу ходить, чтобы сделать JOIN на 4 таблицы вместо того чтобы данные извлекать по очереди. Просто потому что через репозиторий это сделать невозможно не вынося на верх Query(...) который просто окажется абстракцией над решением ORM
Почему такая любоффь к 1С? Да нет никакой любви — банально 99% людей, которых вы принимаете на работу с ней умеют работать.
Чем сильнее конфигурация 1С отличается от стандартной — тем больше с ней возни и проблем.
В интересах конечного заказчика чтобы решение работало просто эффективно
Это решение либо покупается, либо пилится внутри компании усилиями 3-4 разработчиков на каком-то мейнстримовом языке вроде java/c#/go
ru.wikipedia.org/wiki/%D0%9E%D1%82%D0%BD%D0%BE%D1%81%D0%B8%D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D1%8C_%D0%BE%D0%B4%D0%BD%D0%BE%D0%B2%D1%80%D0%B5%D0%BC%D0%B5%D0%BD%D0%BD%D0%BE%D1%81%D1%82%D0%B8
Понятие момент времени вводится для конкретного наблюдателя и конкретной системы отсчёта. Поэтому в таких условиях вообще невозможно говорить об одновременности событий, т.к. событие всего одно — посадка ровера. Факт получения информации об этом событии идёт от Марса до Земли несколько минут. Задержка обусловлена тремя факторами: временем сжатия фото-видео информации (там процессор не быстрый — 133МГц), кодированием информации для передачи и собственно её передачей. И в такой конфигурации может оказаться что сжатие и кодирование даёт существенную добавку к времени передачи фото-видео инфорации.
Автор статьи же намерено троллит людей двумя факторами:
1. Тем что большинство людей не в курсе что в СТО понятие одновременности определено для пары (систем отсчёта + наблюдатель с часами)
2. Что намеренно уводит беседу в область теоретической физики не давая людям вспомнить о суровой правде жизни — радиационно-защищенные процессоры достаточно медленные + об необходимости помехозащищенной передачи данных (гуглите про Вояджер и коды Рида-Соломона)
Билд.
Прогон unit-тестов.
Publish.
Поставка артефактов.
Сейчас это всё можно сделать в виде docker файла. Более того если еще и docker-compose сделать то можно добавить этап прогона интеграционных тестов (если поднять еще базу, redis,rabbit и всё остальное что нужно).
На билдовой машине при этом нужен только docker
2. На уровне .NET Standard 2.0 код нормально шарился между платформами. В крайнем случае можно было настроить multitargeting на netcoreapp2.1, netstandard2.0 и net47. А на .NET Core 3 и 3.1 уже даже WPF заработал.
P.S. Вообще интересно даже что вы там такое использовали, что только .NET 5 нормально стал поддерживать?
1. Почему код сокетов не был переписан на асинхронные сокеты (это не те что async/await, а те что SocketAsyncEventArgs)?
2. Почему не был осуществлен переход на Core 2.x. Я в одном из проектов с Mono под ARM благополучно перешел на core под ARM, а уж 3.1 там поддерживал любые изыски.
При развертывании локально вам нужно чтоб миграции выполнились при старте сервиса. Не всегда используется EF, я, например, использую пару NHibernate и Dapper в зависимости от потребностей
Что касается кодов ошибок, таких кодов не так много.
200 — стандартный ответ
204 — null (реализовано .NET)
На все остальные кидается Exception, который выставляет код ошибки.
Я лично за подход 200 — возвращается всегда когда API правильно отработало запрос, 500 — когда произошла ошибка. Ведь сервисы еще и мониторить надо
Более того часто люди не понимают как это работает — в итоге получаем что у нас есть три enum в разных проектах, которые в друг друга мапятся вместо одно enum.
А задачи по добавлению одного поля в ответ отнимают половину рабочего дня. А если там еще интеграционные тесты на каком-нибудь питоне, то задача по добавлению одного поля может и за 2 дня в мастер не вмерджиться.
Кодогенерацию еще и запускать надо. В новом .NET 5 она уже нормальная станет
Архитектура проекта должна быть такова, чтобы позволять делать вещи удобно и с минимальными усилиями, при этом оставляя проект тестируемым.
Если взять C# то тут:
1. БД должна быть полностью описана миграциями (FluentMigrator)
2. Уровень доступа к БД должен быть покрыт компонентными тестами которые выполняются в Docker (поднимается минимальная рабочая инфраструктура для сервиса)
3. Должны быть интеграционные тесты выполняющие определенные сценарии, также исполняемые в Docker, при этом тесты должны быть внутри этого же решения.
4. Для каждого контроллера делать фасад. Никакой логики в контроллере. В простейшем случае фасад же и будет репозиторием.
5. Никогда не закладывать в начале создания сервиса overhead на репозитории, внутренние сервисы и прочее когда в них нет надобности. В 99% случаев микросервисов достаточно контроллера, фасада и уровня ORM.
6. Давать именам осмысленные названия чтобы проект не состоял из кучи бессмысленных producer,consumer,context и прочего вырвиглаза который не нужно инжектить. Его можно просто создать в том сервисе, который логически за всё это отвечает, а не в инициализации контейнера.
7. Шаблон репозиторий на высокой нагрузке приводит к тому, что код на нём сложно оптимизировать. Например, в процессе оптимизации просто приходится напрямую в базу ходить, чтобы сделать JOIN на 4 таблицы вместо того чтобы данные извлекать по очереди. Просто потому что через репозиторий это сделать невозможно не вынося на верх Query(...) который просто окажется абстракцией над решением ORM