Многие всё ещё используют Управление Торговлей 10.3, она на обычных. Причём, именно поэтому. Новая Торговля удобнее, в ней больше возможностей, но если ради неё надо всему персоналу обновить компьютеры и всё равно она будет на новых компьютерах работать медленнее, чем старая на старых, то уж лучше надёжное работающее решение.
А современный компьютер даже без 1С требует хотя бы 8ГБ, иначе ОС тормозить будет.
Как-то вёл разработки конфигурации в которой объём данных был где-то 30GB.
У другого программиста самый нагруженный отчёт формировался 30 минут, у меня с теми же данными, ОС и конфигурации за четыре минуты.
У него компьютер использовался не для работы, а приятного время провождения.
Windows нужно уметь настроить и тогда всё летает.
Заметьте вопросов разработки вообще в посте не коснулся.
Что касаемо Windows 10 и 11, то не знаю ни одного довода, который бы меня убедил, что они нужны.
То же самое могу сказать о Visual Studio 13.
Нет никакой необходимости в установке иной версии.
Разрабатываемый кроссплатформенный run-time будет производительно работать в любой ОС (и это не бахвальство).
Использую его в 1С, так как в нём много вкусных плюшек.
Windows 98 упомянул лишь в контексте того, что разрабатываемое API будет эффективно работать на любой ОС (суждения о том, что её нужно установить не было).
Ну это уже на какие-то сказки похоже. Сборка большого проекта потребует много гибибайт RAM, никакие танцы с бубном по настройке ОС не помогут (по секрету, и небольшой проект может много сожрать — чем они современные средства разработки кормят, что у них такой аппетит?!).
1) Заходим «Журналы приложений и служб» и отключаем все логи
2) После загрузки Windows удаляем десяток процессов Windows (они совершенно не нужны любому пользовательскому процессу).
3) В службах отключаем использование несколько десятков (они совершенно не нужны любому пользовательскому процессу)
К COM не прикасаемся и даже не смотрим в его сторону, он НУЖЕН (без COM винда станет линуксом).
Какие службы отключаем: «Сервер», «Рабочая станция», ...
Это никак не отразится на работу в домене, ...
4) ...
Это лишь была прелюдия ...
У меня так!
Проблема в том, что многие админы толком то и не знают ничего о службах Windows, настройках эффективной её работы, ...
Но щёки первоклассно надувать умеют и картриджы менять.
Всё как обычно.
За разработку даже заикаться не буду.
Это десять больших ОКЕАНОВ, которые нужно уметь переплыть.
Сложно на форуме вести диалоги.
Многие «спецы» учат, учат, учат ... и постоянно дают знать о том, что они СПЕЦЫ, а оппонент ... (ну вы поняли).
Так как использую конфигурации на 7.7 для отладки run-time API.
Всё дело в том, что API умеет работать с объектами как в memory так и на hdd (не сериализация, а бинарный файл, содержащий данные одного или нескольких объектов).
Так вот любая конфигурация 1С 7.7 (иносказательно) это
иерархическое дерево, содержащие данные
(любая конфигурация 1С 7.7 или 1С 8.3 это по существу некое представление иерархического дерева. Но таковым в memory у них оно не является ),
загружаю в объект, содержащий все метаданные и данные.
Non problem создать объект, который будет содержать метаданные и данные любой конфигурации 1С 8.3 (мне пока это не нужно).
И ещё, объекты создаются динамически согласно метаданных.
Можно к примеру создать объект, который содержит метаданные и данные конфигурации для 1С 7.7 или 1C 8.3.
Разрабатываемое API не является а-ля 1С.
Конфигурации 1С для него это просто некий объект (использую для отладки).
Надеюсь понятно о чём речь.
Но на форуме СПЕЦЫ УЧАТ - «нам смешно, что вы упоминаете 1С 7.7 »
Кстати API корректно работает с любым базовым типом данных (в т.ч. float).
Всё дело в том, что в метаданных поля имеются данные о его значности (для числовых полей).
Для работы с float имеются некоторые «тонкости» и безусловно они учитываются.
Пардон, но что такое «реальная арифметика нашего мира»?
Такая же абстракция как и те два стандарта, просто на более низком уровне. У нее точность вычислений имеет гораздо больше значащих цифр после точки которые пока невозможно учесть в кремниевых процессорах.
Так как в Лисп можно в run-time использовать исходные тексты
модулей, то наверное можно для вашего клиента разработать
run-time генератор Лисп модулей согласно некоего исходного алгоритма или запроса.
Но на форуме СПЕЦЫ УЧАТ - «нам смешно, что вы упоминаете 1С 7.7 »
Упоминание вами v7.7 было сделано в контексте указания недостатков платформы 1С, на что вам справедливо заметило несколько комментаторов что аппелировать к версии 15 летней давности в этом случае не уместно. Это как обсуждать винду и двигать тезисы уровня «Современная Windows плохая потому что Windows 8 не могла…».
Вместо того чтобы просто принять аргумент и продолжить обсуждение вы начинаете рассказывать как хорошо вы владеете v7.7 (мы за вас рады, серьезно, хорошо когда человек - специалист) и пытаетесь «давить авторитетом» скатываясь к концу спитча в Лавсановщину. Не нужно.
Синтаксис у 1С простой. Проблема в огромной стандартной библиотеке. Там одна ТаблицаЗначений чего стоит с операциями свёртки, сортировки и индексированного поиска.
А клиента и начал делать, потому что местами синтаксиса 1С явно не хватает.
Мне проще.
Разрабатываемое API позволяет работать с: переменными, массивами, списками, деревьями, ... (но это не а-ля 1С API).
Из а-ля 1С, лишь API для работы с mxl, но оно не «прибито гвоздями» к 1С, а использует API run-time.
Ладно, расскажу одну из причин почему разработал API для работы с mxl.
Можно перенести исходные тексты отчётов из 1С 7.7 в 1С 8.3 ничего не изменяя в исходном коде (но это не основная причина).
Акцентирую то, что API run-time можно использовать в бинарном коде любого ЯП.
Да, но используются не переменные 1С, а переменные из run-time.
Функционирует всё на удивление просто.
В исходном коде 1С ничего менять не нужно, 1С использует переменные run-time как свои родные.
В run-time переменные не Variable, но при их использовании они конвертируются в Variable.
Скорость выполнения даже чуть выше чем в родном коде 1С, так как эффективность «подсаживает» COM.
Вот когда разработаю свой объектно-ориентированный ЯП, тогда всё будет многократно эффективней (начал его разработку, но приостановил из-за того, что разработка GUI, более приоритетная задача).
Простой пример:
// Переменные, используемые для формирования отчета
//
typedef struct НаселПункты__ {
TCHAR *VpPage; // Номер листа
TCHAR *Header001; // Заголовок шапки
INT VpКод; // Код населенного пункта
INT VpКодСбыт; // Код в отделе сбыт
TCHAR *VpНазвУлицы; // Название улицы
TCHAR *LinkПотребитель; // Расшифровка
TCHAR *VpНаимОператора; // Наименование оператора
TCHAR *VpПодпись; // Подпись
} НаселПункты_; // typedef struct НаселПункты__ {
Ещё раз акцентирую, что API работает в run-time и компиляторы «c досады нервно грызут ногти».
На самом деле может быть использовано много *.h и любой вложенности #include.
В struct поддержан общепринятый синтаксис и расширенный (определения семантики полей и struct).
В частности в struct возможно использовать инициализацию полей и структур, ..., ...
У меня это именуется подсистемой поддержки сишного интерфейса (можно использовать метадата базы, ...).
Имеются конечно разные способы задания метаданных.
Много чего «сказать есть».
В постах лишь немножко рассказал о разрабатываемом API.
Sorry, хотя и использую 1С уже лет двадцать, но СТО ПУДОВ не считаю себя 1С-ником.
Разработчикам 1С РЕСПЕКТ.
Ещё немножко.
API для работы с mxl использует freetype (перевёл его на C++, убрал десятки макросов, ..., но название оставил исходное).
Через какое-то время опубликую исходники.
Разработано лишь процентов 10 - 15 от планируемого.
В частности будет разработано API для использования баз знаний.
Не разрабатываю а-ля 1С.
Разрабатываемое API - кроссплатформенное core, которое можно будет использовать в любом проекте на любом ЯП.
Это же SAP. Он известен своим подходом «вы должны переделать свой бизнес под наш софт».
А в статье этот тезис вообще не ставится под сомнение:
One would expect the Lidl organization to learn from this lesson. But nothing seems less true. According to the latest reports, the retailer has decided to continue to develop the old, self-developed ‘Wawi’ system. So that they can continue the way of stock valuing in the old, familiar way. And therefore do not have to change.
В 1С гибкости на порядок больше. При необходимости вообще пилится что угодно по желанию заказчика. Я с одним помощником делал из 1С:Управление торговлей 10 систему учёта ремонтами сотовых телефонов. С учётом аналогов деталей, сроков ремонта, стадий ремонта и выпиской всех документов (накладная, кассовый ордер, счёт-фактура) одной кнопкой. Цена вопроса была примерно 200 тысяч рублей. Другим в 1С:Зарплата 2.5 за месяц сделал расчёт зарплаты с расчётным «месяцем» с 27-го по 27-е число.
А здесь за сотни миллионов евро не смогли учёт в закупочных ценах реализовать. Я в шоке.
Аналогично. Собственно, из-за освежающего эффекта мне и полюбилась эта история.
В 1С гибкости на порядок больше.
Мне кажется, тут больше дело в корпоративной культуре, нежели в технических особенностях. Компанию, где я работаю, давеча SAP купила и у меня пол года зад пылал от того, как всё становится сложнее и хуже. Потом привык. Лучше не стало, просто привык.
Мне кажется, тут больше дело в корпоративной культуре, нежели в технических особенностях.
И в технических. 1С всё-таки родня линуксу: вся конфигурация в исходниках, можно легко сделать «такое же, но с перламутровыми пуговицами» или, наоборот, с нуля построить всё, что душа пожелает.
SAP - это даже не Windows. Это старый (до Mac OS X) макинтош. Делать надо именно так, как нами задумано. Делать надо то, что мы задумали. Возможный выбор только в рамках предусмотренного. Если что-то не предусмотрены, то это вам не надо.
Там прямо в начале статьи написано почему не взлетело: About a thousand staff and hundreds of consultants implemented a new company-wide system for inventory control.
Это не техническая проблема. SAP славится своим умением впаривать кровавый энтерпрайз (пролезая в фирму за откаты манагерам) и устроить дойку жирного клиента. В 1С тоже бывают истории распила, но таких крупных факапов я не помню.
Лидл (4 500 магазинов) вполне сможет работать на 1С, также как и Магнит (28 707 магазинов - работает на 1С 8.3) или Пятерочка (19 000 магазинов - работает на 1С еще с версии 7.7). Вот 7-Eleven (79 000 магазинов) может испытать некоторые трудности с масштабированием на 1С, но там больше вопрос к качеству архитектуры.
У 1С есть место, где он не очень хорошо работает: крупные одиночные базы. То есть, когда у тебя не тысячи отдельных магазинов, а один крупный сложный завод.
Например, при внедрении на КАМАЗе, насколько я помню, чуть ли не половину отчётов переписали на прямые запросы к SQL. Скорости платформы на тех масштабах уже не хватало.
Хотя эти проблемы были когда только вышла 8.2. С тех пор уже раза четыре значительно улучшали производительность на крупных базах.
monk, ничего «крутого» в этом нет и всё крайне тривиально.
Просто такого рода API давно должно было быть разработано кем-то другим (задач ведь полно).
Почему так?
Потому что нынешние технологии - «наскальные».
Они вообщем-то как бы и хороши были для 60-х, но ныне двадцать первый век и ЭВМ стали немного другими (хотя «запашёк» у них тот же, что и в 60-х).
вот теже «новомодные» RPA которые по сути автокликеры во многом.
экономика эффективна в предметах «роскоши» - решения устраняющие маржу экономически бессмысленны сами по себе - но только как часть более общего решения дающего прибыль и или вытесняющее опонентов
в чём сила рыночка - продуцирование иммунитета по его сохранению
Так я к тому и веду. Если всем этим прекрсным «a thousand staff and hundreds of consultants» дать в руки 1С, то вот вообще не понятно отчего результат будет иным. Так что «реальный пример который не мог бы быть автоматизирован на 1С» вполне возможнен, ибо помимо технологического, есть и иные аспекты реальности.
Так что «реальный пример который не мог бы быть автоматизирован на 1С» вполне возможнен
Я имел ввиду сугубо технический аспект. А имитацию бурной деятельности за откаты можно проводить в любом проекте, любой сферы деятельности. Это не проблема программного продукта.