Ок, идея понята. Сделаем выбор, либо скролл, либо в столбик, либо сокращения текста.
Редактор интерфейса как раз юзабильный, не всегда удобно делать маленькую иконку вместо обычной кнопки, если есть место для кнопки конечно. Заботились как раз не о его «красоте», а о его юзабельности. Это пример малой его части, есть где-то страшнее, где-то попроще. Кабина пилота тоже ад на непосвещенный взгляд. Но при этом там каждый прибор на своем месте и он там не просто так, он необходим. И на самом деле если чуть вникнуть то все нестрашно становится, а очень удобно.
Каждый элемент интерфейса нужен для выполнения каких-то функций.
И кстати никто не заставляет клиентов вникать в редактор. Если необходимо что-то изменить в конфигурации по мелочи, можно просто позвонить в службу поддержки и это за 10 минут сделают. Главный смысл редактора — можно удобно и оперативно обслуживать клиентов. И индивидуально. То что вы измените, будет только у этого клиента, а не у всех.
Главное — мы это можем делать. Это хороший сервис.
Бывает в меру Вашей испорченности )
Вообще ERP — Enterprise Resource Planning, по русски — планирование ресурсов предприятия. Смысл — управление внутренней жизнью предприятия, организация взаимодействия сотрудников, автоматизация и упрощение бизнес-процессов.
CRM — Customer Relationship Management — система управления взаимоотношениями с клиентами. По сути часть ERP системы, больше нужна для отдела продаж.
Это пример. Вы можете задавать эти свойства. Параметры сокращения текста для того, чтобы влезло в экран мобильного под разные форматы. Хоть целиком его выводите, только будет не очень красиво когда в названии заявки напишут сочинение и оно будет на пол экрана.
Лучше при ограничении ширины текст сокращать, без потери информативности. Понимаете что не информативно — увеличили параметры.
~ более коротко чем… например, тоже экономит ширину при такой же информативности. Это все не просто так.
Или вы знаете пример системы с автоматическим преобразованием в мобильную версию произвольной конфигурации, где применены более интересные решения? С удовольствием ознакомлюсь.
Думаю «автор» имел ввиду CRM/ERP системы которые клиент может ДОРАБОТАТЬ под себя из интерфейса своего аккаунта. Среди них самые популярные.
Битрикс и Амо Вы не доработаете. В Битриксе максимум Вы добавите какие-то поля (на старших тарифах), но созданием нового интерфейса, созданием процедур и триггеров в базе и не пахнет.
Навик — это MS NAV. Очень существенная доля рынка в Европе среди SMB.
Про MS NAV ничего не могу сказать. Не видел. Сейчас только погуглив составил мнение какое-то.
Вообще, начинать статью надо было с этого: «Например 2 первые версии внутреннего языка были забракованы и выкинуты на помойку, потому что в какой-то момент приходило осознание что данный путь в никуда и надо были изначально строить все архитектурно по другому.»
Статья вообще не об этом. У нас зашел разговор про то что БД в системах с возможность внутреннего программирования будут человеконечитаемые базы. Их можно сделать человекочитаемыми, но с увеличением ресурсоемкости и усложнением системы.
Сразу бы стало понятно — очередное изобретение велосипеда. :)))
К чему про велосипед? Если Вы хотите чтобы Ваша система была гибкая, Вам придтся сделать возможность внутреннего программирования. И стандартный язык в облаке Вы не возьмете. О безопасности то тоже надо думать. Причем со всех сторон, докер например с доступом к исходникам тоже не выход если у вас закрытый исходный код ядра — вы его просто откроете в этом случае. IonCube Вам тоже не поможет. Во первых тогда теряется смысл возможности внутреннего программирования, во вторых говорят оно расшифровывается при желании. Обфускация тоже только затрудняет, и не более.
Реально в облаке можно давать программирование только через свой интерфейс. Где тут велосипед то? Это прямая необходимость для данной функциональности.
MS NAV — насколько я понял:
а) коробочная версия
б) не уверен что на их C/AL можно посмотреть код всей системы, иначе появилось бы много MS NAV… сто пудовоу у них ядро закрыто, а редактировать можно только конфигурацию.
К сожалению понятия не имею об их возможностиях по программированию базы, может они вообще стандартными средствами для баз предлагают пользоваться, ибо это коробка.
Но если все через интерфейс и у них стаяла примерно аналогичная задача и они для себя решали примерно аналогичные проблемы. Решили — респект! Но это совершенно не значит что их техническое решение для их системы можно где-то еще использовать. Можно использовать только как концепт.
И вы не поверите, но ЕРП системы в целом и отчеты в частности — нужны только людям. :)))
Наверное да. Видимо схожие технические задачи находят схожие и технические решения. У них наверное тоже когда-то вставала такая проблема.
Только скорее у нас есть п.1 и п.2 из Вашего списка. Или простой редактор, или PL\SQL конфигуратор.
Увидел недавно, что в 1С есть «виртуальные таблицы» состоящие из нескольких реальных. Очень хорошая идея, которая решит некоторые проблемы. Думаю тоже такое сделаем.
Вообще у них все немного концептологически по другому устроено. Насколько я понимаю они в БД хранят только данные, а вся обработка данных выполняется в самой программе.
У нас несколько по другому. В базе хранятся не только данные, но и задается обработка этих данных, путем написания процедур и триггеров на PL\SQL. Благодаря такому решению, мы можем обрабатывать массивы информации на уровне БД, а не на уровне ПО. И думаю у нас благодаря этому проще получился сам компилятор. По сути, нам надо провести преобразование конфигурации пользователя в последовательность SQL команд. У них же (есть у меня подозрение) что переводится в сишные команды, а потом компилируется. Но я не знаю на самом деле как у них, это мои догадки. Может у них просто свой интерпретатор, который исполняет команды их внутреннего языка, но мне кажется это неэффективно будет с точки зрения быстродействия.
Есть у нас кое что и на уровне ПО конечно, например постройка интерфейса, проверка прав доступа и т.п. Но далеко не все.
Видимо поэтому им проще разработать сложный конфигуратор отчетов. А нам проще встроить в конфигуратор отчетов PL\SQL редактор и сразу же предоставить механизмы уровня разработчкика.
Вообще если есть здесь специалисты такого уровня по 1С, было бы интересно узнать как в 1С устроен язык программирования на машинном уровне. Это свой интерпритатор, или конфигурация во что-то компилируется.
Судя по тому что я вижу, это система с заложенной конфигурацией, а не произвольной. Т.е. можно менять только в рамках настроек существующих полей. Или вы можете добавить в интерфейсе какое либо поле [Transaction Type] и оно появится в этой таблице, или в другой если в другой добавите? А если на русском напишите? А как триггер будите компоновать на машинном уровне? Например надо пользователю сделать действие какое-то в другой таблице при апдейте этого поля. «Навик» такое может?
Для системы Вы этим усложните цепочку действий, ей вместо того чтобы подставить ID надо будет по этому ID вычислить наименование поля и подставить его. Вы усложните кучу операций, кучу переборов. Вы столкнетесь с проблемой уникальных наименований, и еще с неизвестно с чем. Наверняка возникнет море дополнительных сложностей.
И кстати каждая дополнительная операция — потеря быстродействия системы, что тоже очень важно.
Осмысленные наименования на машинном уровне — это зло. Это нужно только людям. Я проходил через решения всех этих проблем. Даже без этого было море проблем о которых и предположить изначально было нельзя. Например 2 первые версии внутреннего языка были забракованы и выкинуты на помойку, потому что в какой-то момент приходило осознание что данный путь в никуда и надо были изначально строить все архитектурно по другому. Только с 3 версии получилась боевая программа, которая позволила все сделать.
1) Конструктор отчетов должен удовлетворять потребности руководителей малого-среднего звена, по получению интересующих управленческих данных на основе данных системы. Нельзя быть во всех областях специалистом и всего предусмотреть в типовых отчетах.
2) Конструктор отчетов должен удовлетворять потребности простого персонала, путем получения каких-то простых данных, которые не могут дать типовые отчеты или интерфейс системы. В том числе и путем модифицирования типовых отчетов.
3) Для аналитиков — возможность легкого получения набора данных из системы для загрузки в специализированные программы и последующего анализа там.
4) Собственно сама возможность для разработчиков быстрым и удобным образом составлять типовые отчеты и выполнять запросы клиентов.
На самом деле путем 1С никто не шел. Я например базу 1С увидел постфактум и осознал что на самом деле схожие технические задачи просто находят схожие решения. Хотя системы по структуре на самом деле очень сильно отличаются. Чисто визуально базы схожи.
Я не очень люблю на эту тему дискутировать, пробовал уже, но сколько людей — столько и мнений и далеко не все с моим мнением согласны. Но тут как говорится жизнь покажет кто прав а кто нет. Надо просто молча работать над совершенствованием перспективных технологий, пока другие занимаются красивостью виджетов. А далее клиенты уже будут голосовать предпочтением.
У существующих облачных crm на мой взгляд есть очень существенный недостаток. Они не имеют гибкости. Бизнес-процессы они всегда специфичны и глупо всех подгонять под один интерфейс.
Так в целом у всех. Битрикс и КлиентскаяБаза попробовали сделать некую гибкость, предоставив возможность добавлять новые поля, но этого крайне мало. Нужно полностью иметь возможность менять любые элементы интерфейса, создавать любые таблицы, делать любые обработки данных. Причем индивидуально в каждом аккаунте, а не для всех. Только тогда crm система сможет удовлетворить компанию.
Но гибкая система это сложный путь. Надо сначала ее структурировать до мельчайших элементов. Сделать для нее внутренний язык программрования, на котором можно из этих элементов собрать конфигурацию. Обязательное условие, что вся конфигурация системы полность должна быть написана на этом внутреннем языке. Только тогда crm система сможет дать пользователю менять любой из кирпичиков из которых она состоит, или создавать новые конструкции из кирпичиков. Т.е. дать возможность менять интерфейсы, создавать новые структуры хранения данных, новые логики обработки данных.
В ERP-Платформе это в свое время было сделано, и не из соображений что вот есть гибкая 1С и мы тоже так хотим, а именно из соображений описанных выше. На 1С никто даже не смотрел, а смотрели на конкурентов и пытались сделать лучше их.
Сейчас в итоге во первых система может подстраиваться под любого пользователя, во вторых разработка нового идет намного быстрей ибо вместо php можно просто в конструкторе составлять систему.
Благодаря структуризации появился вот тот же конфигуратор отчетов. В обычной статичной crm такого просто не сделают, или сделают опять же статичный, и его надо будет допиливать при каждом изменении системы. А у нас система может меняться, при этом тот же конфигуратор отчетов менять не надо, он все поддерживает.
То же относится и к остальным модулям. На статичной системе где-то изменение сделал, во всех модулях системы это надо менять. У нас же можно сосредоточится на разработке отдельного модуля без заморочек на остальное, оно автоматически все изменения подхватит.
В общем сделать сложно, но в итоге вы увеличите скорость разработки, качество своих сервисов и если клиент попросит что-то подрегулировать под него, вы можете сказать: "Да, мы это можем. Без проблем!".
Да и концепция подтверждена смой жизнью. Как бы кто 1С не любил, но они непоколебимый мастадонт не просто так. По факту ими все пользуются. Каждая компания которую я знаю пользуется 1С. Их не любят из-за фактически монопольного положения, но при этом все равно пользуются и тратят на них деньги. Это потому что у них есть технология, которая позволяет делать индивидуальную подгонку под каждую компанию. Это решающий фактор.
Оглянитесь вокруг, такова жизнь. Кто владеет технологией легкой индивидуальной доработки — тот в будущем будет на коне.
Но это мое мнение. Я не претендую на то что я единственный тут вижу истину, может это не так. Но я думаю жизнь дальнейшая покажет, что выберут клиенты. Пока вот жизнь показывает что выбирают 1С.
Мы кстати с 1С не пытаемся конкурировать, они ушли очень далеко и это непоколебимая скала. Бухгалтерией нет планов заниматься. Но цель вписаться в нишу облачных crm — вполне посильная задача.
тогда и вправду отпадают отчёты с поворотами, rollup и т.д
Я не думаю что простым менеджерам нужны отчеты с поворотами ) это скорее для продвинутых аналитиков надо. Но если прямо вот понадобится и будет востребовано — реализуем. Может быть сами реализуем, а может придумаем способ оптимальной передачи данных в систему которая это умеет. Но пока это не повестка дня.
Можно без проблем выгружать данные в Excel или в упомянутый Вами Tableau и анализировать как угодно. Надо только сначала эти данные получить. Вот получить можно при помощи конфигуратора отчетов и довольно удобным образом. Щелкнули «Ecxel» и пожалуйста, или откроете в экселе, или сохранить как csv и дальше этот же файл можно в Tableau загрузить.
Никто повторить функциональность Tableau не будет в здравом уме (если конечно нет цели войти именно в этот бизнес).
Далее вы не осознаете технических реалий конфигурируемых систем, тем более облачных.
Напрямую дать доступ к базе пользователя из BI системы просто бессмысленно. В конфигурируемых системах база данных не как обычно, а имена таблиц и полей состоят из номеров. Пользователь просто не поймет что есть что, конфигурация системы знает что Задачи это таблица 49, а номер задачи поле в этой таблице с именем 568 и т.п. В общем не вариант. Вы видели когда-нибудь БД 1С?
В ERP-Платформе сырая база еще сложнее, т.к. там помимо хранения данных еще и обработка эти данных, автоматически созданные конфигурацией процедуры, триггеры, системы записи логов и передачи данных и т.п. Это будет как на ассемблере пытаться что-то анализировать… Пользователь общается со всем этим удобным образом через конфигурацию которая знает что есть что на машинном уровне. Пользователю выдает красивые названия и красивый интерфейс. Какие за этим стоят машинные телодвижения — пользователю фиолетово.
Попробуйте в Tableau подключить демо БД от 1С например?
Да и с точки зрения безопасности в облаке никто пускать к себе кого угодно напрямую не будет. В локальной версии еще можно, если это крупная компания и жесткие договорные рамки, но в облачной это просто небезопасно. Работать и выгружать-загружать данные можно только через интерфейс.
Tableau — для тех кто в рамках своей компании занимается разработкой своего продукта, есть своя БД и можно сделать аккаунт на Tableau и анализировать данные из своей БД.
В облачных версиях и в конфигурируемых пользователем системах такое не подходит.
При это есть куча неочевидных кнопок, какие то странные аббревиатуры (COU_D), слова на басурманском (2 desc).
Согласен, это не совсем ясно, но к сожалению ширина экрана ограничена, хочется чтобы все влазило.
«COU» — сокращение от count. Вместо этого можно написать «количество элементов». Вместо «COU_D» можно написать «Количество уникальных элементов». Но вместо 5 букв будет 30 букв. Не удобно. Расползется все в ширь.
Для пояснения есть приписки, если навести мышку на заголовок столбца, то выскакивает пояснение.
Аналогично с сортировкой. Можно написать «Поле 2 сортировка обратная», а можно кратко «2 desc» и соотвественно пояснение что есть что.
В общем из-за экономии ширины экрана пришлось сделать так.
Посмотрим. Если будет прямо массовое непонимание — переименуем в длинное но более читаемое, это не проблема, 5 секунд.
И все равно программизм прорывается (Параметр №2 Varchar_250).
Да, вы правы тут. Давно очень делалось, когда конфигураторами отчетов еще и не пахло. Переименовал в более человеческое.
Как писали выше, есть вполне удачные стандартные средства (Jasper Reports, например).
Не подойдет. Мы не можем пускать абы кого из интернета к исходникам наших баз. Плюс вы заставите писать пользователей SQL запросы в оригинальную базу, которой они не знают. Jasper Reports — хорошо для индивидуальной разработки в локальной сети.
Потом добавите в свой конструктор sql(Ибо иначе не справится со всеми требованиями)… И будет это уже Ваш внутренний инструмент.
В этом нет необходимости, у нас в отчеты можно встраивать процедуры, а для процедур уже есть редактор PL\SQL. Интерфейс отчетов сам по себе остается простым.
Здравствуйте!
Да, конечно. Я про 1С не могу ничего плохого сказать. У них хорошая система отчетов. Но для неподготовленного пользователя она сложна. У них нет различия, простой отчет или сложный, в любом случае пользователю придется иметь дело с конструктором запросов.
Смысл как раз в том, чтобы конструирования запросов избежать в простых случаях. А в сложных, простой пользователь все равно не сделает и придется программиста привлекать.
Главная сложность балансировки нагрузки, что нельзя рвать сессии. Если например на веб ресурсе авторизация сохраняется в сессии, пользователь при обновлении страницы должен попасть на тот же вебсервер, где записана его сессия. Иначе он будет все время отваливаться… Подскажите, как у docker-а с этим?
Но стало интересно. Провел еще более сложный эксперимент.
Например Вася и Петя взяли файл, одновременно отредактировали в нем разные вещи.
Пусть исходный будет (test1.vi):
Вася сделал так (test2.vi)
Петя сделал так (test3.vi)
Сначала сливает Вася, все ок.
xdelta3 -e -s /var/tmp/test1.vi /var/tmp/test2.vi /var/tmp/patch
xdelta3 -d -s /var/tmp/test1.vi /var/tmp/patch /var/tmp/test_res.vi
Потом с результирующим файлом (после Васи) сливает Петя.
Вычисляем разницу между файлом после обновления Васи и Петеным
xdelta3 -e -s /var/tmp/test_res.vi /var/tmp/test3.vi /var/tmp/patch2
Патчим в новый
xdelta3 -d -s /var/tmp/test_res.vi /var/tmp/patch2 /var/tmp/test_res2.vi
И получаем test_res2=test3. Т.е. изменения Васи были затерты Петей.
Вообще на мой взгляд это нерешаемая ситуация и с точки зрения текстового файла в diff. Ибо вот как слить итоговый:
так:
или так:
т.е. без подсказки программа не сможет понять сделать ей преобразование в текст до умножения или после.
Да, все верно, расхождений нет.
Один только нюанс, в специализированном языке постараются сделать чтобы логика была подбна типовому. Иначе никого просто не научите. Да и авторы языка делать ведь его будут не на пустом месте, а исходя из своего опыта в других языках и видения того что надо изменить в лучшую сторону.
интересует только завтраты на получение конечного продукта
Это один из пунктов ради которого и делается. Затраты на разработку движка разовые, зато потом идет постоянный выигрыш в скорости разработки на постоянной основе. В итоге это выигрышно.
По LabView — то что преподавали это хорошо. Я рад что преподают. Но мне кстати не преподавали а кинули сразу в бой, садись и разбирайся, и первые 3 дня мне тоже казалось дичью. Но когда пошла именно боевая практика, я понял насколько это офигенская штука в итоге. Просто кода учат, не пропускаешь через себя все нюансы. Нужна практика.
Редактор интерфейса как раз юзабильный, не всегда удобно делать маленькую иконку вместо обычной кнопки, если есть место для кнопки конечно. Заботились как раз не о его «красоте», а о его юзабельности. Это пример малой его части, есть где-то страшнее, где-то попроще. Кабина пилота тоже ад на непосвещенный взгляд. Но при этом там каждый прибор на своем месте и он там не просто так, он необходим. И на самом деле если чуть вникнуть то все нестрашно становится, а очень удобно.
Каждый элемент интерфейса нужен для выполнения каких-то функций.
И кстати никто не заставляет клиентов вникать в редактор. Если необходимо что-то изменить в конфигурации по мелочи, можно просто позвонить в службу поддержки и это за 10 минут сделают. Главный смысл редактора — можно удобно и оперативно обслуживать клиентов. И индивидуально. То что вы измените, будет только у этого клиента, а не у всех.
Главное — мы это можем делать. Это хороший сервис.
Вообще ERP — Enterprise Resource Planning, по русски — планирование ресурсов предприятия. Смысл — управление внутренней жизнью предприятия, организация взаимодействия сотрудников, автоматизация и упрощение бизнес-процессов.
CRM — Customer Relationship Management — система управления взаимоотношениями с клиентами. По сути часть ERP системы, больше нужна для отдела продаж.
Лучше при ограничении ширины текст сокращать, без потери информативности. Понимаете что не информативно — увеличили параметры.
~ более коротко чем… например, тоже экономит ширину при такой же информативности. Это все не просто так.
Или вы знаете пример системы с автоматическим преобразованием в мобильную версию произвольной конфигурации, где применены более интересные решения? С удовольствием ознакомлюсь.
Битрикс и Амо Вы не доработаете. В Битриксе максимум Вы добавите какие-то поля (на старших тарифах), но созданием нового интерфейса, созданием процедур и триггеров в базе и не пахнет.
Про MS NAV ничего не могу сказать. Не видел. Сейчас только погуглив составил мнение какое-то.
Статья вообще не об этом. У нас зашел разговор про то что БД в системах с возможность внутреннего программирования будут человеконечитаемые базы. Их можно сделать человекочитаемыми, но с увеличением ресурсоемкости и усложнением системы.
К чему про велосипед? Если Вы хотите чтобы Ваша система была гибкая, Вам придтся сделать возможность внутреннего программирования. И стандартный язык в облаке Вы не возьмете. О безопасности то тоже надо думать. Причем со всех сторон, докер например с доступом к исходникам тоже не выход если у вас закрытый исходный код ядра — вы его просто откроете в этом случае. IonCube Вам тоже не поможет. Во первых тогда теряется смысл возможности внутреннего программирования, во вторых говорят оно расшифровывается при желании. Обфускация тоже только затрудняет, и не более.
Реально в облаке можно давать программирование только через свой интерфейс. Где тут велосипед то? Это прямая необходимость для данной функциональности.
MS NAV — насколько я понял:
а) коробочная версия
б) не уверен что на их C/AL можно посмотреть код всей системы, иначе появилось бы много MS NAV… сто пудовоу у них ядро закрыто, а редактировать можно только конфигурацию.
К сожалению понятия не имею об их возможностиях по программированию базы, может они вообще стандартными средствами для баз предлагают пользоваться, ибо это коробка.
Но если все через интерфейс и у них стаяла примерно аналогичная задача и они для себя решали примерно аналогичные проблемы. Решили — респект! Но это совершенно не значит что их техническое решение для их системы можно где-то еще использовать. Можно использовать только как концепт.
Верю, я об этом и писал статью…
Только скорее у нас есть п.1 и п.2 из Вашего списка. Или простой редактор, или PL\SQL конфигуратор.
Увидел недавно, что в 1С есть «виртуальные таблицы» состоящие из нескольких реальных. Очень хорошая идея, которая решит некоторые проблемы. Думаю тоже такое сделаем.
Вообще у них все немного концептологически по другому устроено. Насколько я понимаю они в БД хранят только данные, а вся обработка данных выполняется в самой программе.
У нас несколько по другому. В базе хранятся не только данные, но и задается обработка этих данных, путем написания процедур и триггеров на PL\SQL. Благодаря такому решению, мы можем обрабатывать массивы информации на уровне БД, а не на уровне ПО. И думаю у нас благодаря этому проще получился сам компилятор. По сути, нам надо провести преобразование конфигурации пользователя в последовательность SQL команд. У них же (есть у меня подозрение) что переводится в сишные команды, а потом компилируется. Но я не знаю на самом деле как у них, это мои догадки. Может у них просто свой интерпретатор, который исполняет команды их внутреннего языка, но мне кажется это неэффективно будет с точки зрения быстродействия.
Есть у нас кое что и на уровне ПО конечно, например постройка интерфейса, проверка прав доступа и т.п. Но далеко не все.
Видимо поэтому им проще разработать сложный конфигуратор отчетов. А нам проще встроить в конфигуратор отчетов PL\SQL редактор и сразу же предоставить механизмы уровня разработчкика.
Вообще если есть здесь специалисты такого уровня по 1С, было бы интересно узнать как в 1С устроен язык программирования на машинном уровне. Это свой интерпритатор, или конфигурация во что-то компилируется.
Судя по тому что я вижу, это система с заложенной конфигурацией, а не произвольной. Т.е. можно менять только в рамках настроек существующих полей. Или вы можете добавить в интерфейсе какое либо поле [Transaction Type] и оно появится в этой таблице, или в другой если в другой добавите? А если на русском напишите? А как триггер будите компоновать на машинном уровне? Например надо пользователю сделать действие какое-то в другой таблице при апдейте этого поля. «Навик» такое может?
Для системы Вы этим усложните цепочку действий, ей вместо того чтобы подставить ID надо будет по этому ID вычислить наименование поля и подставить его. Вы усложните кучу операций, кучу переборов. Вы столкнетесь с проблемой уникальных наименований, и еще с неизвестно с чем. Наверняка возникнет море дополнительных сложностей.
И кстати каждая дополнительная операция — потеря быстродействия системы, что тоже очень важно.
Осмысленные наименования на машинном уровне — это зло. Это нужно только людям. Я проходил через решения всех этих проблем. Даже без этого было море проблем о которых и предположить изначально было нельзя. Например 2 первые версии внутреннего языка были забракованы и выкинуты на помойку, потому что в какой-то момент приходило осознание что данный путь в никуда и надо были изначально строить все архитектурно по другому. Только с 3 версии получилась боевая программа, которая позволила все сделать.
1) Конструктор отчетов должен удовлетворять потребности руководителей малого-среднего звена, по получению интересующих управленческих данных на основе данных системы. Нельзя быть во всех областях специалистом и всего предусмотреть в типовых отчетах.
2) Конструктор отчетов должен удовлетворять потребности простого персонала, путем получения каких-то простых данных, которые не могут дать типовые отчеты или интерфейс системы. В том числе и путем модифицирования типовых отчетов.
3) Для аналитиков — возможность легкого получения набора данных из системы для загрузки в специализированные программы и последующего анализа там.
4) Собственно сама возможность для разработчиков быстрым и удобным образом составлять типовые отчеты и выполнять запросы клиентов.
Если в качестве уникальных идентификаторов вместо чисел будете использовать читаемые наименования — флаг вам в руки )
Поделитесь примером где это не так. Интересно.
Я не очень люблю на эту тему дискутировать, пробовал уже, но сколько людей — столько и мнений и далеко не все с моим мнением согласны. Но тут как говорится жизнь покажет кто прав а кто нет. Надо просто молча работать над совершенствованием перспективных технологий, пока другие занимаются красивостью виджетов. А далее клиенты уже будут голосовать предпочтением.
У существующих облачных crm на мой взгляд есть очень существенный недостаток. Они не имеют гибкости. Бизнес-процессы они всегда специфичны и глупо всех подгонять под один интерфейс.
Так в целом у всех. Битрикс и КлиентскаяБаза попробовали сделать некую гибкость, предоставив возможность добавлять новые поля, но этого крайне мало. Нужно полностью иметь возможность менять любые элементы интерфейса, создавать любые таблицы, делать любые обработки данных. Причем индивидуально в каждом аккаунте, а не для всех. Только тогда crm система сможет удовлетворить компанию.
Но гибкая система это сложный путь. Надо сначала ее структурировать до мельчайших элементов. Сделать для нее внутренний язык программрования, на котором можно из этих элементов собрать конфигурацию. Обязательное условие, что вся конфигурация системы полность должна быть написана на этом внутреннем языке. Только тогда crm система сможет дать пользователю менять любой из кирпичиков из которых она состоит, или создавать новые конструкции из кирпичиков. Т.е. дать возможность менять интерфейсы, создавать новые структуры хранения данных, новые логики обработки данных.
В ERP-Платформе это в свое время было сделано, и не из соображений что вот есть гибкая 1С и мы тоже так хотим, а именно из соображений описанных выше. На 1С никто даже не смотрел, а смотрели на конкурентов и пытались сделать лучше их.
Сейчас в итоге во первых система может подстраиваться под любого пользователя, во вторых разработка нового идет намного быстрей ибо вместо php можно просто в конструкторе составлять систему.
Благодаря структуризации появился вот тот же конфигуратор отчетов. В обычной статичной crm такого просто не сделают, или сделают опять же статичный, и его надо будет допиливать при каждом изменении системы. А у нас система может меняться, при этом тот же конфигуратор отчетов менять не надо, он все поддерживает.
То же относится и к остальным модулям. На статичной системе где-то изменение сделал, во всех модулях системы это надо менять. У нас же можно сосредоточится на разработке отдельного модуля без заморочек на остальное, оно автоматически все изменения подхватит.
В общем сделать сложно, но в итоге вы увеличите скорость разработки, качество своих сервисов и если клиент попросит что-то подрегулировать под него, вы можете сказать: "Да, мы это можем. Без проблем!".
Да и концепция подтверждена смой жизнью. Как бы кто 1С не любил, но они непоколебимый мастадонт не просто так. По факту ими все пользуются. Каждая компания которую я знаю пользуется 1С. Их не любят из-за фактически монопольного положения, но при этом все равно пользуются и тратят на них деньги. Это потому что у них есть технология, которая позволяет делать индивидуальную подгонку под каждую компанию. Это решающий фактор.
Оглянитесь вокруг, такова жизнь. Кто владеет технологией легкой индивидуальной доработки — тот в будущем будет на коне.
Но это мое мнение. Я не претендую на то что я единственный тут вижу истину, может это не так. Но я думаю жизнь дальнейшая покажет, что выберут клиенты. Пока вот жизнь показывает что выбирают 1С.
Мы кстати с 1С не пытаемся конкурировать, они ушли очень далеко и это непоколебимая скала. Бухгалтерией нет планов заниматься. Но цель вписаться в нишу облачных crm — вполне посильная задача.
Я не думаю что простым менеджерам нужны отчеты с поворотами ) это скорее для продвинутых аналитиков надо. Но если прямо вот понадобится и будет востребовано — реализуем. Может быть сами реализуем, а может придумаем способ оптимальной передачи данных в систему которая это умеет. Но пока это не повестка дня.
Можно без проблем выгружать данные в Excel или в упомянутый Вами Tableau и анализировать как угодно. Надо только сначала эти данные получить. Вот получить можно при помощи конфигуратора отчетов и довольно удобным образом. Щелкнули «Ecxel» и пожалуйста, или откроете в экселе, или сохранить как csv и дальше этот же файл можно в Tableau загрузить.
Никто повторить функциональность Tableau не будет в здравом уме (если конечно нет цели войти именно в этот бизнес).
Далее вы не осознаете технических реалий конфигурируемых систем, тем более облачных.
Напрямую дать доступ к базе пользователя из BI системы просто бессмысленно. В конфигурируемых системах база данных не как обычно, а имена таблиц и полей состоят из номеров. Пользователь просто не поймет что есть что, конфигурация системы знает что Задачи это таблица 49, а номер задачи поле в этой таблице с именем 568 и т.п. В общем не вариант. Вы видели когда-нибудь БД 1С?
В ERP-Платформе сырая база еще сложнее, т.к. там помимо хранения данных еще и обработка эти данных, автоматически созданные конфигурацией процедуры, триггеры, системы записи логов и передачи данных и т.п. Это будет как на ассемблере пытаться что-то анализировать… Пользователь общается со всем этим удобным образом через конфигурацию которая знает что есть что на машинном уровне. Пользователю выдает красивые названия и красивый интерфейс. Какие за этим стоят машинные телодвижения — пользователю фиолетово.
Попробуйте в Tableau подключить демо БД от 1С например?
Да и с точки зрения безопасности в облаке никто пускать к себе кого угодно напрямую не будет. В локальной версии еще можно, если это крупная компания и жесткие договорные рамки, но в облачной это просто небезопасно. Работать и выгружать-загружать данные можно только через интерфейс.
Tableau — для тех кто в рамках своей компании занимается разработкой своего продукта, есть своя БД и можно сделать аккаунт на Tableau и анализировать данные из своей БД.
В облачных версиях и в конфигурируемых пользователем системах такое не подходит.
Согласен, это не совсем ясно, но к сожалению ширина экрана ограничена, хочется чтобы все влазило.
«COU» — сокращение от count. Вместо этого можно написать «количество элементов». Вместо «COU_D» можно написать «Количество уникальных элементов». Но вместо 5 букв будет 30 букв. Не удобно. Расползется все в ширь.
Для пояснения есть приписки, если навести мышку на заголовок столбца, то выскакивает пояснение.
Аналогично с сортировкой. Можно написать «Поле 2 сортировка обратная», а можно кратко «2 desc» и соотвественно пояснение что есть что.
В общем из-за экономии ширины экрана пришлось сделать так.
Посмотрим. Если будет прямо массовое непонимание — переименуем в длинное но более читаемое, это не проблема, 5 секунд.
Да, вы правы тут. Давно очень делалось, когда конфигураторами отчетов еще и не пахло. Переименовал в более человеческое.
Не подойдет. Мы не можем пускать абы кого из интернета к исходникам наших баз. Плюс вы заставите писать пользователей SQL запросы в оригинальную базу, которой они не знают. Jasper Reports — хорошо для индивидуальной разработки в локальной сети.
В этом нет необходимости, у нас в отчеты можно встраивать процедуры, а для процедур уже есть редактор PL\SQL. Интерфейс отчетов сам по себе остается простым.
Да, конечно. Я про 1С не могу ничего плохого сказать. У них хорошая система отчетов. Но для неподготовленного пользователя она сложна. У них нет различия, простой отчет или сложный, в любом случае пользователю придется иметь дело с конструктором запросов.
Смысл как раз в том, чтобы конструирования запросов избежать в простых случаях. А в сложных, простой пользователь все равно не сделает и придется программиста привлекать.
diff может показать разницу между бинарными, но patch-ем насколько я знаю вы не сольете их.
У меня получилось слить так.
xdelta3 -e -s /var/tmp/test1.vi /var/tmp/test2.vi /var/tmp/patch
xdelta3 -d -s /var/tmp/test1.vi /var/tmp/patch /var/tmp/test_res.vi
Результирующий файл открылся. Проблем нет.
Но стало интересно. Провел еще более сложный эксперимент.
Например Вася и Петя взяли файл, одновременно отредактировали в нем разные вещи.
Пусть исходный будет (test1.vi):
Вася сделал так (test2.vi)
Петя сделал так (test3.vi)
Сначала сливает Вася, все ок.
xdelta3 -e -s /var/tmp/test1.vi /var/tmp/test2.vi /var/tmp/patch
xdelta3 -d -s /var/tmp/test1.vi /var/tmp/patch /var/tmp/test_res.vi
Потом с результирующим файлом (после Васи) сливает Петя.
Вычисляем разницу между файлом после обновления Васи и Петеным
xdelta3 -e -s /var/tmp/test_res.vi /var/tmp/test3.vi /var/tmp/patch2
Патчим в новый
xdelta3 -d -s /var/tmp/test_res.vi /var/tmp/patch2 /var/tmp/test_res2.vi
И получаем test_res2=test3. Т.е. изменения Васи были затерты Петей.
Вообще на мой взгляд это нерешаемая ситуация и с точки зрения текстового файла в diff. Ибо вот как слить итоговый:
так:
или так:
т.е. без подсказки программа не сможет понять сделать ей преобразование в текст до умножения или после.
При помощи клавиатуры и мышки…
Причем тут язык то, вам нужна хорошая система контроля версий
Я извиняюсь, но времени не очень много с вами спорить днями и писать сочинения с доказательствами. Дел и так полно. Я уже написал вроде все.
Один только нюанс, в специализированном языке постараются сделать чтобы логика была подбна типовому. Иначе никого просто не научите. Да и авторы языка делать ведь его будут не на пустом месте, а исходя из своего опыта в других языках и видения того что надо изменить в лучшую сторону.
Это один из пунктов ради которого и делается. Затраты на разработку движка разовые, зато потом идет постоянный выигрыш в скорости разработки на постоянной основе. В итоге это выигрышно.
По LabView — то что преподавали это хорошо. Я рад что преподают. Но мне кстати не преподавали а кинули сразу в бой, садись и разбирайся, и первые 3 дня мне тоже казалось дичью. Но когда пошла именно боевая практика, я понял насколько это офигенская штука в итоге. Просто кода учат, не пропускаешь через себя все нюансы. Нужна практика.