Вы читали статью? Есть два гитлаба, нужно синхронизировать исходники между ними, это требование заказчика. Мы ведем разработку в своем гитлабе, но еще выкладываем копию исходников в гитлаб заказчика.
Целевой сервер Gitlab не дает настроить стандартное зеркалирование, равно как и обратное зеркалирование, являющееся premium-фичей
Оба разработчика создают разные файлы, поскольку решают разные задачи. Следовательно, их пути не пересекаются. Об этом написано в статье, в разделе Liquibase.
Если у разработчиков пересекаются объекты, то это ненормальная ситуация, которая скорее всего говорит о неправильной постановке задач. Если же это задачи вида «добавить в таблицу T колонку A» для первого разработчика и «добавить в таблицу T колонку B» для второго, то оба изменения пройдут успешно. Это не конфликт.
Деплой на прод сводится к формированию релиза, т.е., упрощенно, к мержу из дева в прод. Скрипты подтягиваются и накатываются в том же порядке, что и на деве. Это зона ответственности Liquibase.
По этой схеме разработчики работали уже не первый год, и серьезных проблем не возникало.
Если выбрать поход с includeAll, конфликтов не будет, потому что задача разработчиков баз данных будет сводиться к добавлению файлов чейнжсетов.
Впрочем, даже с использованием include и правкой общего файла, конфликты вполне решаются через интерфейс гитлаба, потому что каждый разработчик добавляет свой скрипт в конец файла-аккумулятора.
Делать обновление версии на бэке значительно проще, но это не всегда возможно. Суть моего решения в автономности фронта.
Например, если фронт не имеет бэка или если фронт может обновляться независимо от него.
В дополнение к прочим комментариям добавлю, что ресурсы нужно освобождать.
В вашем случае, это объект WebClient, т.е. нужно было обернуть его создание в конструкцию using или (для последних версий C#) написать
using var wb = new WebClient();
В общем, статья больше похожа на вредный совет, как писать не нужно.
В комментарии ниже был ответ, но мне не сложно повторить =)
Сейчас все регионы переходят на прямые расчеты между поставщиками ресурсов и конечными потребителями, прокладка в виде УК будет убираться. В регионах создаются биллинговые системы, с которыми мы интегрируемся + задействуем функционал ГИС ЖКХ, где согласно законодательству должны работать абсолютно все РСО и УК страны. И если ваша УК не принимает показания через этот сервис – повод обратиться в Инспекцию жилнадзора.
Это к вопросу о передаче показаний. А что касается вопросов о том, что за прибор висит на счетчике – покажете им паспорт нашего устройства, т.к. мы будем его сертифицировать.
P.S. Что касается меня лично, то я никогда не пускаю их в квартиру, т.к. не считаю их требование осматривать счетчики законными, да и зачем, если есть обязательная поверка.
Никак, т.к. жители в этом не заинтересованы.
А так и без устройства ничто не мешает передать в УК заведомо ложные показания, но никто этим не занимается.
Сейчас все регионы переходят на прямые расчеты между поставщиками ресурсов и конечными потребителями, прокладка в виде УК будет убираться. В регионах создаются биллинговые системы, с которыми мы интегрируемся + задействуем функционал ГИС ЖКХ, где согласно законодательству должны работать абсолютно все РСО и УК страны. И если ваша УК не принимает показания через этот сервис – повод обратиться в Инспекцию жилнадзора. Так что софт для работы у всех УК есть.
Мы же решаем проблему тех пользователей, кому влом, неудобно снимать показания или кто постоянно об этом забывает.
По креплению – на рендерах не все учтено, крепление конечно будет =) Что-то более близкое к реальности – на фото прототипа устройства, который был собран на простой ардуинке. Сейчас мы работаем над максимальным снижением его размеров и проработкой крепления, чтобы была возможность цеплять его не только сверху, но и заводя сбоку.
С электросчетчиками тоже делаем диверсификацию моделей – для многотарифных счетчиков будем делать решение на фоторезисторе и считывать импульсы потребления.
Даааа, сайт – наше слабое место, тут каемся. Делали по-быстрому в Сенеже, а скрипты я выкладывал на сервер во время доклада =). В ближайшее время его переделаем.
По вопросам:
1. Сейчас занимаемся промдизайном GeMeter, в том числе – креплением. В концепции – упругая скоба, удерживающая GeMeter на счетчике. Водяные счетчики не строгого размера, но типизированы. Вариация размеров между производителями – в пределах 1 см, так что наше решение будет достаточно универсальным. Кроме того, GeMeter будет отличаться в зависимости от типов счетчиков. Что касается электрических – да, там есть проблема с местом, поэтому мы рассматриваем вариант выносного считывателя. Вообще, на первых порах нет цели и возможности охватить 100% видов счетчиков, т.к. бывают и такие, где для отображения показаний нужно физически нажать на кнопку.
2. Да, будет 2 варианта – под симку и с Wi-Fi модулем.
3. Пока только со своим. А в какие сторонние сервисы есть желание подключить?
Здесь главный вопрос – а зачем передавать показания в управляющую компанию раз в час? Это не только избыточно, но и УК вам спасибо не скажет. Такая частота может быть интересна либо промышленным предприятиям, либо ресурсникам. Обычным пользователям это не нужно, разве что для статистики и/или обнаружения протечек. Кроме того, если нам удастся разработать более экономичный вариант устройства, мы сможем снимать показания и чаще. Раз в месяц – минимальная и вполне достаточная частота для работы.
Нам не известно о законодательном запрете на закрытие показаний, кроме того, бывают устройства вообще без циферблата (но GeMeter с ними не работает =) ). Мы сами сейчас работаем над вариантом с открытым циферблатом, т.к. это просто визуально более интересное решение. А отображение на лицевой части данных на индикаторе излишне, т.к. наша концепция в том, что пользователь вообще забывает про свои счетчики и не смотрит на них.
Мы принципиально не используем nb сети по причине их малого распространения. Да, эти сети обладают рядом преимуществ, но на сегодняшний день они развернуты только в крупных городах и далеко не каждый желающий может к ним подцепиться. Наше решение на GSM и Wi-Fi сетях направлено на решение именно этой проблемы – его можно использовать не только в мегаполисах, но и в любых малых городах.
Показания счетчиков жители передают 1 раз в месяц, большая частота передачи показаний просто не нужна, так что от 2 батареек ААА Gemeter живет до 2 лет. Само устройство за рамками периодов передачи данных находится в спящем режиме и просыпается только для снятия показаний и передачи данных.
Очень интересный вопрос по распространению счетчиков с уже интегрированной электроникой – тот же СТРИЖ на рынке уже более 5 лет, и установлено по их заявлениям 300 тыс. устройств. Так что о широком распространении таких устройств говорят уже давно, но по факту никто не торопится их массово внедрять.
Тема передачи данных от таких устройств в управляющие организации – это как раз основная задача, которую мы решаем. Мы это делаем с помощью интеграции нашего сервиса с региональными и федеральными биллинговыми системами.
Сам недавно занимался распознаванием печатного текста с фотографии и рукописных цифр.
Потому могу порекомендовать использовать для распознавания печатных букв Tesseract, а OpenCV можно использовать для предварительной обработки изображения – удаление шумов, выделение контуров. Внутри Tesseract 4 также есть нейронная сеть, обученная на большом количестве шрифтов. Есть версии разного качества для различных языков, в т.ч. и для русского.
Что касается MNIST, – он тоже работает только в тепличных условиях. Я использовал обученную модель LightGMB, которая имеет точность ~98.5% на тестовых данных, но при этом не распознает цифры с реальных фотографий. Причина в том, что мало подогнать цифру под размер 28*28, нужно сделать дополнительную обработку изображения, а именно – сжать цифру до 20*20 пикселей, а потом сместить от центра в направлении, противоположном центру массы изображения. Это сложно объяснить на пальцах, но такой подход повышает точность в несколько раз. Есть ли подобная проблема у EMNIST, мне неизвестно.
P.S. Еще известная проблема MNIST заключается в том, что он собран на данных америкосов, если посмотреть на картинки, то можно увидеть, что некоторые цифры они пишут совсем не так, как нас учили в школе. Это также ощутимо влияет на качество распознавания этих цифр.
Немного запоздало, но все же оставлю ссылку на свой пост о генерации IL-кода: https://habr.com/ru/post/251765/.
Пример там не абстрактный, а вполне рабочий, применяемый в реальных проектах.
Ну а что касается ассемблера, использовать его в C# смысла не вижу, язык создан не для этого. Кроме того, теряется кроссплатформенность, которая является главной (на мой взгляд) фишкой .NET Core, а за ним будущее всего .NET.
Вы читали статью? Есть два гитлаба, нужно синхронизировать исходники между ними, это требование заказчика. Мы ведем разработку в своем гитлабе, но еще выкладываем копию исходников в гитлаб заказчика.
Штатное средство недоступно из-за правил ИБ.
Я вижу пустые строки в токенах, а вы?
Где, простите, вы увидели захардкоженные токены?
Скрипт примерно это и делает, но при чем здесь форки? Нельзя сделать форки между двумя изолированными гитлабами.
Нужно иметь две копии исходников на разных серверах Gitlab, которые не имеют связи между собой. Может вы с Github'ом перепутали?
Желательно начать отвыкать, потому что многие библиотеки отходят от Newtonsoft.Json, теперь это лишний оверхед.
System.Text.Json позволяет делать ту же сериализацию в одну строчку, при этом не надо тянуть никаких зависимостей:
JsonSerializer.Serialize(data)По этой схеме разработчики работали уже не первый год, и серьезных проблем не возникало.
Если выбрать поход с includeAll, конфликтов не будет, потому что задача разработчиков баз данных будет сводиться к добавлению файлов чейнжсетов.
Впрочем, даже с использованием include и правкой общего файла, конфликты вполне решаются через интерфейс гитлаба, потому что каждый разработчик добавляет свой скрипт в конец файла-аккумулятора.
Например, если фронт не имеет бэка или если фронт может обновляться независимо от него.
В вашем случае, это объект WebClient, т.е. нужно было обернуть его создание в конструкцию using или (для последних версий C#) написать
В общем, статья больше похожа на вредный совет, как писать не нужно.
Сейчас все регионы переходят на прямые расчеты между поставщиками ресурсов и конечными потребителями, прокладка в виде УК будет убираться. В регионах создаются биллинговые системы, с которыми мы интегрируемся + задействуем функционал ГИС ЖКХ, где согласно законодательству должны работать абсолютно все РСО и УК страны. И если ваша УК не принимает показания через этот сервис – повод обратиться в Инспекцию жилнадзора.
Это к вопросу о передаче показаний. А что касается вопросов о том, что за прибор висит на счетчике – покажете им паспорт нашего устройства, т.к. мы будем его сертифицировать.
P.S. Что касается меня лично, то я никогда не пускаю их в квартиру, т.к. не считаю их требование осматривать счетчики законными, да и зачем, если есть обязательная поверка.
А так и без устройства ничто не мешает передать в УК заведомо ложные показания, но никто этим не занимается.
Можно подключать несколько адресов, если вы, например, сдаете квартиру в аренду или ставите устройство на дачу.
Мы же решаем проблему тех пользователей, кому влом, неудобно снимать показания или кто постоянно об этом забывает.
По креплению – на рендерах не все учтено, крепление конечно будет =) Что-то более близкое к реальности – на фото прототипа устройства, который был собран на простой ардуинке. Сейчас мы работаем над максимальным снижением его размеров и проработкой крепления, чтобы была возможность цеплять его не только сверху, но и заводя сбоку.
С электросчетчиками тоже делаем диверсификацию моделей – для многотарифных счетчиков будем делать решение на фоторезисторе и считывать импульсы потребления.
По вопросам:
1. Сейчас занимаемся промдизайном GeMeter, в том числе – креплением. В концепции – упругая скоба, удерживающая GeMeter на счетчике. Водяные счетчики не строгого размера, но типизированы. Вариация размеров между производителями – в пределах 1 см, так что наше решение будет достаточно универсальным. Кроме того, GeMeter будет отличаться в зависимости от типов счетчиков. Что касается электрических – да, там есть проблема с местом, поэтому мы рассматриваем вариант выносного считывателя. Вообще, на первых порах нет цели и возможности охватить 100% видов счетчиков, т.к. бывают и такие, где для отображения показаний нужно физически нажать на кнопку.
2. Да, будет 2 варианта – под симку и с Wi-Fi модулем.
3. Пока только со своим. А в какие сторонние сервисы есть желание подключить?
Нам не известно о законодательном запрете на закрытие показаний, кроме того, бывают устройства вообще без циферблата (но GeMeter с ними не работает =) ). Мы сами сейчас работаем над вариантом с открытым циферблатом, т.к. это просто визуально более интересное решение. А отображение на лицевой части данных на индикаторе излишне, т.к. наша концепция в том, что пользователь вообще забывает про свои счетчики и не смотрит на них.
Показания счетчиков жители передают 1 раз в месяц, большая частота передачи показаний просто не нужна, так что от 2 батареек ААА Gemeter живет до 2 лет. Само устройство за рамками периодов передачи данных находится в спящем режиме и просыпается только для снятия показаний и передачи данных.
Очень интересный вопрос по распространению счетчиков с уже интегрированной электроникой – тот же СТРИЖ на рынке уже более 5 лет, и установлено по их заявлениям 300 тыс. устройств. Так что о широком распространении таких устройств говорят уже давно, но по факту никто не торопится их массово внедрять.
Тема передачи данных от таких устройств в управляющие организации – это как раз основная задача, которую мы решаем. Мы это делаем с помощью интеграции нашего сервиса с региональными и федеральными биллинговыми системами.
Потому могу порекомендовать использовать для распознавания печатных букв Tesseract, а OpenCV можно использовать для предварительной обработки изображения – удаление шумов, выделение контуров. Внутри Tesseract 4 также есть нейронная сеть, обученная на большом количестве шрифтов. Есть версии разного качества для различных языков, в т.ч. и для русского.
Что касается MNIST, – он тоже работает только в тепличных условиях. Я использовал обученную модель LightGMB, которая имеет точность ~98.5% на тестовых данных, но при этом не распознает цифры с реальных фотографий. Причина в том, что мало подогнать цифру под размер 28*28, нужно сделать дополнительную обработку изображения, а именно – сжать цифру до 20*20 пикселей, а потом сместить от центра в направлении, противоположном центру массы изображения. Это сложно объяснить на пальцах, но такой подход повышает точность в несколько раз. Есть ли подобная проблема у EMNIST, мне неизвестно.
P.S. Еще известная проблема MNIST заключается в том, что он собран на данных америкосов, если посмотреть на картинки, то можно увидеть, что некоторые цифры они пишут совсем не так, как нас учили в школе. Это также ощутимо влияет на качество распознавания этих цифр.
Пример там не абстрактный, а вполне рабочий, применяемый в реальных проектах.
Ну а что касается ассемблера, использовать его в C# смысла не вижу, язык создан не для этого. Кроме того, теряется кроссплатформенность, которая является главной (на мой взгляд) фишкой .NET Core, а за ним будущее всего .NET.