CRM-система для УК и ТСЖ

ГИС ЖКХ: Предложения по информационному обмену

Будете спамить рекламой - будем нещадно банить)))
Сообщение
Автор
Аватар пользователя
Rembo
Ветеран
Сообщений: 3787
Зарегистрирован: 01 июл 2015, 17:29
Благодарил (а): 5733 раза
Поблагодарили: 4725 раза

ГИС ЖКХ: Предложения по информационному обмену

#71 Сообщение Rembo » 07 ноя 2016, 20:57

AlcorVol писал(а):Источник цитаты Вообще-то, тема - не о том.

Финансы - двигатель прогресса и ускоритель реакции.

two_oceans
Бывалый
Сообщений: 438
Зарегистрирован: 30 сен 2016, 17:17
Благодарил (а): 386 раза
Поблагодарили: 351 раза

ГИС ЖКХ: Предложения по информационному обмену

#72 Сообщение two_oceans » 08 ноя 2016, 09:59

МихаилИгоревич писал(а):Готов частично профинансировать разработку веб сервиса для 1с, а также выступить разработчиком ТЗ.
1c это немного другое, там специфический Visual Basic с русским акцентом. Конечно это достойно отдельного обсуждения, работающих в 1с немало и есть платный модуль для гисгмп, так что есть с чего начать. Кстати, модуль для ГИС жкх вроде бы тоже есть, в соседнем разделе обсуждали как замечательно все синхронизируется с 1с, но кажется выгрузка-загрузка вручную. Вот тут начали что-то делать по автоматизации, но похоже пока не очень-то ладится и им посоветовали тоже сделать сервис на C#. Я за 1с не возьмусь - так как там специфическое обновление форм и как представлю что это все править после каждой смены версии форматов гис жкх, становится дурно.
Теоретически,если все же сделать DLL автоматической смены отчетов, можно подумать как прикрутить к 1с. Пока что проектирую DLL для обертки и отправки уже готовых данных, до подготовки самих отчетов еще не скоро дело дойдет.

Аватар пользователя
OStepanych
Новичок
Сообщений: 14
Зарегистрирован: 10 ноя 2016, 20:33
Откуда: N-ск
Благодарил (а): 58 раза
Поблагодарили: 4 раза
Контактная информация:

ГИС ЖКХ: Предложения по информационному обмену

#73 Сообщение OStepanych » 10 ноя 2016, 22:44

Из 1С7.7 выгрузил через Excel 2003 (плюс конвертор) 80 квартир в шаблон МКД. ГИС принял, обработал.
Формат MXL да, очень хочется.

Sergey Cheban
Стажер
Сообщений: 112
Зарегистрирован: 05 ноя 2016, 07:45
Благодарил (а): 55 раза
Поблагодарили: 60 раза

ГИС ЖКХ: Предложения по информационному обмену

#74 Сообщение Sergey Cheban » 13 ноя 2016, 09:50

Прошу прощения за поздний ответ. Я сейчас в командировке, со временем напряг.
AlcorVol писал(а):Умный софт должен сам анализировать ошибки. И если это ошибка оператора - подсказывать ему, что надо исправить.

Чтобы софт стал умным и хотя бы не делал свои ошибки (бог с ними, с ошибками оператора), этот софт надо сначала отладить. Желательно, не на "боевых" данных, а на тестовых.
Собственно, ГИС ЖКХ сейчас кривая в том числе и потому, что отлаживать её было не на чем.
AlcorVol писал(а):
Sergey Cheban писал(а):Источник цитаты Требование по подключению к ГИС ЖКХ - вполне рыночное обстоятельство: сильные выживут, слабые помрут.

Это - искусственно созданное обстоятельство. Малый бизнес (основа среднего класса) и без того всюду выдавливается с рынка монополиями. Просто тут наблюдаем очередной удар ему по башке.

Обстоятельства вполне естественные: необходимость навести порядок в ЖКХ - объективна, а компьютеризация процессов способствует выявлению узких мест (что будет после выявления - вопрос отдельный). И ликвидация малого бизнеса в том виде, в котором он сейчас существует - тоже процесс естественный.

Отправлено спустя 6 минуты 29 секунды:
Programmer писал(а):
Sergey Cheban писал(а):Источник цитаты Требование по подключению к ГИС ЖКХ - вполне рыночное обстоятельство: сильные выживут, слабые помрут.

А не похоже ли это на монополию, это требование?

Нет, не похоже. У нас не одна сильная команда программистов.

Programmer писал(а):Это почти про меня. XML я умею, но описание его содержимого оставляет желать лучшего.

На это мне пока нечего ответить. Но это уже _другая_ проблема.

Аватар пользователя
AlcorVol
Активист
Сообщений: 163
Зарегистрирован: 20 окт 2016, 00:40
Откуда: Вологда
Благодарил (а): 629 раза
Поблагодарили: 159 раза

ГИС ЖКХ: Предложения по информационному обмену

#75 Сообщение AlcorVol » 13 ноя 2016, 10:29

Sergey Cheban писал(а):Источник цитаты Чтобы софт стал умным и хотя бы не делал свои ошибки (бог с ними, с ошибками оператора), этот софт надо сначала отладить.

Согласен. И где же специальные "средства отладки" при загрузке информации через XLSX? Их просто нет. Только ответные диагностики. Вот, их-то и надо показывать оператору. Другого выхода нет. И если диагностики связаны с программными ошибками, то потребуется, конечно, доработка программы. В иных случаях реагировать придётся оператору.
Sergey Cheban писал(а):И ликвидация малого бизнеса в том виде, в котором он сейчас существует - тоже процесс естественный.

Здесь - категорически не соглашусь. Но это - тема не для нашего форума.

Sergey Cheban
Стажер
Сообщений: 112
Зарегистрирован: 05 ноя 2016, 07:45
Благодарил (а): 55 раза
Поблагодарили: 60 раза

ГИС ЖКХ: Предложения по информационному обмену

#76 Сообщение Sergey Cheban » 13 ноя 2016, 11:04

two_oceans писал(а):Я уже тут писал, что на данный момент система авторизации на ГИС ЖКХ заслуживает самое мягкое определения "крайне непродуманная". В стране все еще много тех, кто не зарегистрирован на Госуслугах - в основном это пенсионеры. А пенсионеров - треть населения страны. И они очень часто являются формальными владельцами. Итого, минимум треть квартир даже в принципе (не обращая внимание на то, что Росреестр привязывается как попало) не могут зайти и посмотреть, что же там УО внесли.

Не вижу проблемы. Чтобы подключить лицевой счёт к личному кабинету, не обязательно быть собственником. Достаточно знать адрес и номер лицевого счёта (который, очевидно, должен фигурировать в бумажных квитанциях).

two_oceans писал(а):
SOAP в ЛК
Это конечно была шутка, забавное преувеличение. но! в каждой шутке как известно только доля шутки. ЭП на файлы передаваемые в ЛК не ставится, кто отправитель заранее известно, так что SOAP от XML практически не отличается в этом случае.

Вообще-то если по уму, то следовало бы требовать подпись и от файлов, передаваемых через ЛК.

two_oceans писал(а):
Sergey Cheban писал(а):Источник цитаты Протокол SOAP - открытый. И вот с этой точки - пожалуйста, сами, если можете. А если не можете, то и говорить не о чем. А DLL - это очень, очень плохая идея:Непонятная DLL, работающая с криптографией и имеющая доступ к приватным ключам - это не безопасно.DLL привязывает нас к платформе Windows.Интерфейс, предоставляемый DLL - это чистый C. Даже не C++. Работать с ним из современных языков программирования неудобно.DLL выполняется в адресном пространстве чужого процесса. Если в результате процесс падает, не всегда понятно, по чьей вине это произошло. Нет внятного разграничения зон ответственности.В DLL наверняка были бы ошибки. Распространение DLL с исправлениями этих ошибок - задача нетривиальная.
По пунктам:
1) Более половины реализации SOAP одинаково не только в рамках ГИС ЖКХ, но и вообще всех российских ФГИС (все что вне Body по большому счету описано SOAP, отличий не так уж много). То есть что разработчиков множество это плохо, а что государство не предложит единую реализацию SOAP, на которую могли бы ориентироваться те же разработчики будущих ФГИС, это нормально - как хотите так и плывите. Правильно Вас понимаю?

Реализации SOAP предлагает не государство, а разработчики языков программирования и библиотек.

two_oceans писал(а):2) небезопасно, согласен. Но все криптопровайдеры тоже в своем составе имеют DLL, естественно подписанные и сертифицированные ФСБ. Им вы доверяете? И при этом лично звонили проверяли подлинность сертификата? Ну и прекрасно, используем их.

Плевать на сертификат ФСБ. Главное, чтобы софт, установленный на той машине, с которой есть доступ к приватному ключу, не умел втихаря генерировать подпись для текста "Продаю всё своё имущество имяреку за 1 (один) рубль".

two_oceans писал(а):Понятно, если бы библиотека была подписана подписью ГИС ЖКХ или КриптоПро к ней было бы больше доверия, чем к "левому" разработчику, потому и просим.

Деньги давать не пробовали? А то вот у меня к еде из магазина больше доверия, чем к еде с помойки, но это же не причина, чтобы попрошайничать.

two_oceans писал(а):3) На Linux есть аналог DLL - SO библиотеки.

С ними - ровно те же самые проблемы, что и с виндовыми dll. И по тем же техническим причинам.

two_oceans писал(а):4) Здравствуйте, при всем уважении, а кроме семейства Си языки какие-то знаете? У меня например мои все DLL на Паскале. Главное, что бы формат параметров можно было описать на любом языке - неважен язык программирования разработчика DLL.

Ага, сейчас.
- Разные языки программирования - это причина существования в компиляторах от MS ключевых слов __stdcall и __cdecl.
- Предположим, у нас есть простенькая функция:
__declspec(dllexport) std::string foo(const std::string &d) {return d;} Сможете Вы вызвать её из Паскаля? Вряд ли. Я именно об этом. А сишный интерфейс (const char *) - устарел и неудобен.

two_oceans писал(а):Если же Вы имеете ввиду ООП при работе самой библиотеки, то огромное количество COM объектов как раз используют фабрики экземпляров в виде DLL и OCX TLB (расширение не особо имеет значение - по сути это тоже внешний исполняемый код, подгружаемый программой). Но COM объекты как раз и привяжут нас к Windows. dotNet полагаю тоже?

SOAP нас к винде не привязывает. А com-объекты - да, привязали бы не хуже dll.

two_oceans писал(а):5) Ошибки есть везде и зона ответственности не разграничена, согласен. Но посмотрим, в среднем процессе Windows 7 вовлечены более чем 100 библиотек - не потому что разработчик программы их все загрузил, а потому системные и околосистемные библиотеки тянут за собой огромное количество зависимостей. В этом смысле, если добавится еще одна библиотека, погоды это не сделает.

Те DLL, которые грузятся при старте обычной программы, в основном созданы MS - компанией с очень серьёзным подходом к качеству ПО. В России аналогов нет. Да и у MS регулярно находят проблемы.

two_oceans писал(а):Для этого есть современные средства отладки собирающие данные активности на момент сбоя во всех потоках процесса. Определить, что вылетело при выполнении такой-то функции - на раз.

Это если оно вылетело. А если memory corruption? Такое тоже ищется, но ох не сразу.


two_oceans писал(а):Тут хочу высказаться о языке программирования, на котором сделана библиотека - компиляторы Паскаля как раз славятся тем, что при загрузке модуля (будь то программа или библиотека) сразу же запрашивается память у системы "про запас", не через getmem, а как еще один сегмент наряду с кодом и данными (в них

Это всё детали реализации. Пока не решены проблемы с интерфейсами, не вижу смысла это обсуждать.

two_oceans писал(а):6) проблемы обновления DLL абсолютно такие же, как и у программы, а именно - что заменить файл модуля, который запущен в данный момент, мягко говоря, непросто.

Технически - такие же. Юридически - нет: если нет DLL, то техподдержка ГИС ЖКХ избавляется от разговоров про эту DLL.

Sergey Cheban
Стажер
Сообщений: 112
Зарегистрирован: 05 ноя 2016, 07:45
Благодарил (а): 55 раза
Поблагодарили: 60 раза

ГИС ЖКХ: Предложения по информационному обмену

#77 Сообщение Sergey Cheban » 13 ноя 2016, 19:39

AlcorVol писал(а):
Sergey Cheban писал(а):Источник цитаты Чтобы софт стал умным и хотя бы не делал свои ошибки (бог с ними, с ошибками оператора), этот софт надо сначала отладить.

Согласен. И где же специальные "средства отладки" при загрузке информации через XLSX? Их просто нет. Только ответные диагностики. Вот, их-то и надо показывать оператору. Другого выхода нет. И если диагностики связаны с программными ошибками, то потребуется, конечно, доработка программы. В иных случаях реагировать придётся оператору.

Что-то я потерял нить разговора. Помнится, начинали мы с того, что злые разработчики ГИС ЖКХ заставляют бедных разработчиков подключаться к своим тестовым стендам. Я говорил, что без тестового стенда невозможно выловить ошибки софта, работающего с ГИС ЖКХ, и этот стенд - не зло, а полезная штука.

Если Вам диагностики не хватает - ну ок, это может быть проблемой. Хотя тут тоже аккуратно надо, чтобы не дойти до диагностики вида "Ошибка в 13 бите пароля".

Аватар пользователя
AlcorVol
Активист
Сообщений: 163
Зарегистрирован: 20 окт 2016, 00:40
Откуда: Вологда
Благодарил (а): 629 раза
Поблагодарили: 159 раза

ГИС ЖКХ: Предложения по информационному обмену

#78 Сообщение AlcorVol » 13 ноя 2016, 22:13

Sergey Cheban писал(а):Источник цитаты Что-то я потерял нить разговора. Помнится, начинали мы с того, что злые разработчики ГИС ЖКХ заставляют бедных разработчиков подключаться к своим тестовым стендам.

Ну, не надо утрировать. :) Перечитайте всё, написанное выше. Особое внимание обратите на объём документации по взаимодействию ИС с ГИС через Web-сервисы. Сам подход никак не предполагает, что каждое ТСЖ будет регистрироваться как "собственная ИС" (в понимании разработчиков ГИС), проходить испытания на стенде и выходить на промышленную эксплуатацию. А не хотите так - долбите ручками в Экселе. Такая вот "альтернатива". Они никак не предполагали, что куча народу будет искать средства автоматического формирования XLSX-файлов...

Впрочем, я уже повторяюсь. И предлагаю не толочь воду в ступе. Ваша позиция мне понятна. Надеюсь, что моя Вам - тоже.

two_oceans
Бывалый
Сообщений: 438
Зарегистрирован: 30 сен 2016, 17:17
Благодарил (а): 386 раза
Поблагодарили: 351 раза

ГИС ЖКХ: Предложения по информационному обмену

#79 Сообщение two_oceans » 14 ноя 2016, 12:32

Sergey Cheban писал(а):Источник цитаты Не вижу проблемы. Чтобы подключить лицевой счёт к личному кабинету, не обязательно быть собственником. Достаточно знать адрес и номер лицевого счёта (который, очевидно, должен фигурировать в бумажных квитанциях).
Что-то я такой опции не увидел. И никаких "наводок" на это тоже. Поищу еще, если получится - премного благодарен.
Sergey Cheban писал(а):Источник цитаты Вообще-то если по уму, то следовало бы требовать подпись и от файлов, передаваемых через ЛК.
Это да. но раз полагаются на ПЭП Госуслуг, нам проще.
Sergey Cheban писал(а):Источник цитаты Реализации SOAP предлагает не государство, а разработчики
Согласен, но государство покупает реализации SOAP для центральных узлов СМЭВ - ничего не мешает включить в ТЗ пункт про библиотеку для свободного распространения. Бог с реализацией, но на данный момент каждая ГИС дополняет формат SOAP как в голову придет разработчикам ГИС. Минкомсвязь могло бы утвердить правила, уточняющие как именно дополнять стандарт - в какое место файла располагать ЭП, как стандартно указывать отправителя/получателя и тд. В конце концов, Little Endian или Big Endian использовать в кодировке ЭП. Это явно задача государства, а не разработчиков, которые реализуют только один вариант, но при этом никто не может внятно объяснить, почему нельзя по другому- в ГОСТ это не указано. Тем не менее, другой вариант возвращается с ошибкой - "Неверная ЭП".
Sergey Cheban писал(а):Источник цитаты С ними - ровно те же самые проблемы, что и с виндовыми dll. И по тем же техническим причинам.
Конечно, но это другая платформа, то есть привязка к Windows - мнимая. Тот же код программы, который напишете на Си будет скомпилирован и упакован в разный формат исполняемых файлов для разных операционных систем.
Sergey Cheban писал(а):Источник цитаты Деньги давать не пробовали?
Что это изменит? Качество вряд ли будет выше пропорционально сумме. Другой вопрос - кому? Реализация SOAP в ГИС довольно неполная и кривоватая, нет никакой гарантии, что другая неполная же реализация других разработчиков совпадет "по кривизне" и будет работать. В магазине Вам тоже могут предложить Столичный хлеб, когда вы пришли за Бородинским. Даже если с одной ГИС будет, хотелось бы универсальную библиотеку для всех федеральных ГИС. А если тем же, кто разрабатывал ГИС, то их компании и так уже заплатило государство (а государство это взяло из налогов и штрафов, то есть с нас с Вами в том числе) и совершенно немалые суммы. Честно, меня просто жаба задавит добавлять к тем суммам.
Sergey Cheban писал(а):Источник цитаты Разные языки программирования - это причина существования в компиляторах от MS ключевых слов __stdcall и __cdecl.
Знаю. Я в это когда-то вникал и смогу вызвать функцию, хотя возможно это займет время, чтобы разобрать код на Си и подобрать аналогичное описание объекта на Паскале. Либо подключить другую библиотеку того же языка, реализующую этот объект - если не вникать как объект устроен, а просто скормить, что передали и получить, что нужно либо наоборот. Как правило ключевые слова меняют порядок аргументов, так что для функции с одним аргументом мало что изменится, пример неудачен.
(я таки на Си не пишу, но немного разбираю, char * - указатель на буфер сразу, std::string &d вроде бы указатель на объект из которого еще надо получить указатель на буфер через c_str и длину через length/size, в этом смысле достаточно каким-то образом реализовать или подключить c_str и size. Скорее даже не так - объекты обычно хранят указатели на реализованные методы объекта, то есть достаточно найти в объекте нужный указатель на уже реализованную функцию c_str и узнать как ей передать объект). В общем, я не так хорошо знаю Си, а Вы похоже вообще не знаете Паскаль, примеры тут бессмысленно обсуждать.
Для информации - в Паскале таких ключевых слов тоже с десяток, включая вышеназванные - это раз. Если ни одно не подойдет, то никто не отменял возможность сделать "оберточную функцию" и вставить в код на Паскале операторную скобку asm .. end и написать внутри код ассемблера для передачи параметров и вызова импортируемой функции - это два. Конечно, при этом вся типизация коту под хвост и возможны ошибки. Но, надеюсь Вы не считаете, что разные языки для передачи параметров компилируют какой-то иной машинный код, несовместимый с ассемблером под ту же архитектуру процессора? Можно еще проще, просто используем stdcall - большинство языков умеет работать с системными библиотеками. Итого: остается просто описать заголовки (ну или оберточные функции) на нужном языке, а проблема не стоит выеденного яйца - решаем один раз, потом миллионы раз вызываем функцию.
Sergey Cheban писал(а):Источник цитаты Да и у MS регулярно находят проблемы.
Да и большая часть из них именно переполнение буфера, то есть по сути именно memory corruption. Это именно болезнь языка Си и прямого использования char * - даже хотя есть вариант функций с указанием размера, многие даже в Майкрософт на это плюют и используют функции без ограничения размера либо неправильно вычисляют ограничение. В Паскале все жестче - например, обычный string (shortstring в моей IDE) ограничен 255 байтами и (используя стандартные функции, без обращения к символам по номеру и махинаций с указателями) 256-ой записать невозможно в принципе - при любой записи берется минимум из ограничения и ожидаемого размера данных. Конечно, 255 байт откровенно сказать мало, но тут ничего не мешает найти исходник встроенного типа по образцу сделать собственный тип скажем на 10 мегабайт и тоже жестко вшить в него ограничение.
Sergey Cheban писал(а):Источник цитаты Пока не решены проблемы с интерфейсами, не вижу смысла это обсуждать.
Учитывая, выше про stdcall, не вижу проблем. Интерфейс всегда можно доработать, если Вам удобнее получать строчку в std::string чем в голом char * то это предмет переговоров о включении дополнительной "оберточной" функции. Либо мне тоже std::string понравится и я портирую объект на Паскаль. Но тут как раз может вылезти что объект не такой уж и std (стандартный), а отличается в разных Си.
Sergey Cheban писал(а):Источник цитаты Технически - такие же. Юридически - нет: если нет DLL, то техподдержка ГИС ЖКХ избавляется от разговоров про эту DLL.
я и не говорил, что это именно техподдержка ГИС ЖКХ будет по DLL по SOAP работу вести, так как федеральных ГИС много, и желательно общую библиотеку. Есть ситуационный центр электронного правительства. Как вариант, сама компания-разработчик библиотеки. А вот конкретно по библиотеке отчетов для ГИС ЖКХ, там конечно техподдержка этой ГИС и тут все понятно (в смысле наоборот непонятно, с чего начинать).

Programmer
Ветеран
Сообщений: 524
Зарегистрирован: 09 окт 2016, 16:39
Благодарил (а): 3420 раза
Поблагодарили: 514 раза

ГИС ЖКХ: Предложения по информационному обмену

#80 Сообщение Programmer » 14 ноя 2016, 13:18

Для разработчиков на Паскале (Delphi) напомню, что строковые переменные и в DLL и в программе должны иметь тип shortstring. Все другие строковые типы, указатели на них, а так же примочки в виде делфийских DLL не работают или работают некорректно!


Вернуться в «ГИС ЖКХ. Форум разработчиков программного обеспечения и всего, что с ним связано»

Кто сейчас на форуме

Количество пользователей, которые сейчас просматривают этот форум: нет зарегистрированных пользователей и 1 гость