С родным языком нельзя не дружить - носитель языка априори его использует правильно. При этом многие "грамотные" путают живой язык и литературную норму - вот с последней как раз можно и не дружить.
Я писал не столько про то, что у военных есть свой сленг и языковые привычки, а про то, что они зачастую прям считают своим долгом ЯВНО поправить того, кто по их мнению ошибся. Но вот в обратку такое получать отчего-то не любят.
Есть сильное подозрение, что имел место не злой умысел на тормозить развитие, а банально ушел тот кто писал конфигуратор и проект встал из-за огромного накопленного техдолга. В пользу этого говорит то, что доработки конфигуратора последние годы уж слишком косметические.
В итоге оказалось проще написать новый ibcmd / ibsrv для перевода разработки в EDT, чем дописывать 20+ летнее легаси.
Ничего себе флэшбеки... Прям как сейчас помню адрес веб-сайта: www.pmicro.kz
Описание детективных поисков одной из старейших ИТ компаний Казахстана удивило - все таки не настолько ж ноунейм это с действующим офисом в самом центре Караганды:
Получается, и в целом разработка в Конфигураторе - луддизм?
Нет - луддизм именно разработка в хранилище. Несмотря на то, что конфигуратор намертво встал в развитии средств разработки, он все еще вполне функциональное IDE.
Платформа обзавелась различными инструментами импорта/экспорта файлов конфигурации на диск, что позволило вынести часть разработки из конфигуратора. Тот же EDT в конечном итоге гоняет исходники в ИБ через эти инструменты.
Уже давно не так. А в текущий момент (вторая половина 2026 года) разработка в хранилище это лютый сознательный луддизм. Оправданием может быть разве, что легаси-проект на обычных формах.
При первом приближении - с какой-такой стати сидящие в ПВЗ за 30к/мес люди будут хоть чем-то рулить в ВАШЕМ бизнесе? Люди которые хотя бы представляют себе что значит "рулить" в чужом бизнесе стоят кратно больше, а те которые умеют на порядок.
Очень сильно подозреваю, что бизнес-модель и основные экономические показатели ПВЗ рассчитаны как микро-бизнес, где владелец один из работников оного, а не эффективный менеджер. Т.е. в принципе модель пассивного дохода к ним не применима.
Отдельно порадовало, про мега-планы по открытию сетки в 100+ ПВЗ в Череповце. Парень явно чей надо сын, и имеет весьма специфическое понятие о "заниматься бизнесом".
Если так сложно доработать 1С для связи с модульной кроссплатформенной CRM с продуманной архитектурой, то надо доработать эту самую отличную CRM. Ведь это же гораздо проще. Не надо нанимать отдел разработчиков - пара строк на питоне пишется любой ИИ-шкой через простой промпт.
Но почему-то бизнесы упорно пытаются доработать 1С, а не эти отличные модульные приложения. Вот даже странно, отчего так?
Настоящая автоматизация — это когда цифровой инструмент встроен в цикл управления: вы ставите цели, измеряете динамику, принимаете решения быстрее и точнее.
Кто это "вы"? Там где управленцы могут и ставят задачи с измеримыми показателями, проблем с автоматизацией управления не возникает.
Проблема в том, что управленцев, которые могут видят и управляют бизнесом хотя бы сопоставимо, с тем, как это делают в Revolut очень, нет, ОЧЕНЬ мало.
Система автоматизации тут вторична - автоматизируя бардак, получаем автоматизированный бардак.
В чем плюс 1Сников - что хотя бы базовый бардак типовыми решениями закрывается. Толковый консультант по 1С вполне может на уровне топ-руководителей объяснить, чем их "гениальные" решения в области учета чреваты.
Компетенции по управлению бизнесом, а уж тем более по консультированию в этой области стоят совсем других денег.
ИНН 770600861904. В бизнесе, как минимум с 1997 года. Только один из известных объектов недвижимости оценивался в 100+ миллионов рублей. Регалии, звания, награды, в т.ч. государственные. И на голубом глазу "под влиянием мошенников"...
Типовые от 1С все таки написаны довольно хорошо, и вполне могут доживать до сотен пользователей без доработок кода и архитектуры. Чего зачастую не скажешь о партнерских решениях - там временами прям сборники "как не надо делать"
Все верно, код в 1с по прежнему выполняется в один поток. На клиенте это вполне нормально - бизнес-логика там не выполняется, а переключать доступность кнопок и одного потока достаточно.
На сервере же, у каждого серверного вызова свой отдельный поток. И хотя внутри код по прежнему выполняется линейно, сервер отлично масштабируется под текущую нагрузку - потоков создается столько сколько нужно. Дальше уже потоками рулит операционка.
Если же хочется какой-то алгоритм сделать многопоточным, то велком в ад фоновых заданий.
С родным языком нельзя не дружить - носитель языка априори его использует правильно. При этом многие "грамотные" путают живой язык и литературную норму - вот с последней как раз можно и не дружить.
Я писал не столько про то, что у военных есть свой сленг и языковые привычки, а про то, что они зачастую прям считают своим долгом ЯВНО поправить того, кто по их мнению ошибся. Но вот в обратку такое получать отчего-то не любят.
Дошутились: торговый флот Монголии в два раза больше торгового флота РФ.
Вы пробовали на ранних версиях MacOS вынуть дискету на включенном компе? А на выключенном? Вот где пример "юзабилити" мака прям очень нагляден.
Зато наверняка не путал "курок" со "спусковым крючком" и говорил "крайний" вместо "последний".
Есть сильное подозрение, что имел место не злой умысел на тормозить развитие, а банально ушел тот кто писал конфигуратор и проект встал из-за огромного накопленного техдолга. В пользу этого говорит то, что доработки конфигуратора последние годы уж слишком косметические.
В итоге оказалось проще написать новый ibcmd / ibsrv для перевода разработки в EDT, чем дописывать 20+ летнее легаси.
Кхм, в программе четко написано Плюс/Микро, Караганда, 1991. Вполне конкретная отправная точка для поиска.
Впрочем, с моей стороны тут явно искажение восприятия, т.к. я как раз в то время жил в Караганде, и как "компьютерщик" конечно знал про эту фирму.
Большое вам спасибо, что всколыхнули воспоминания и рассказали об этих замечательных людях.
Ничего себе флэшбеки... Прям как сейчас помню адрес веб-сайта: www.pmicro.kz
Описание детективных поисков одной из старейших ИТ компаний Казахстана удивило - все таки не настолько ж ноунейм это с действующим офисом в самом центре Караганды:
Скрытый текст
https://yandex.ru/maps/org/plyus_mikro/40547737927
А зачем EDT на контуре эксплуатации? Это инструмент разработки.
Нет - луддизм именно разработка в хранилище. Несмотря на то, что конфигуратор намертво встал в развитии средств разработки, он все еще вполне функциональное IDE.
Платформа обзавелась различными инструментами импорта/экспорта файлов конфигурации на диск, что позволило вынести часть разработки из конфигуратора. Тот же EDT в конечном итоге гоняет исходники в ИБ через эти инструменты.
В EDT round-trip для мелких изменений вообще незаметен. Там же инкрементальные обновления конфигурации делаются.
Как раз в части поправил код на диске -> проверил в Предприятии у EDT отличные показатели.
Уже давно не так. А в текущий момент (вторая половина 2026 года) разработка в хранилище это лютый сознательный луддизм. Оправданием может быть разве, что легаси-проект на обычных формах.
При первом приближении - с какой-такой стати сидящие в ПВЗ за 30к/мес люди будут хоть чем-то рулить в ВАШЕМ бизнесе? Люди которые хотя бы представляют себе что значит "рулить" в чужом бизнесе стоят кратно больше, а те которые умеют на порядок.
Очень сильно подозреваю, что бизнес-модель и основные экономические показатели ПВЗ рассчитаны как микро-бизнес, где владелец один из работников оного, а не эффективный менеджер. Т.е. в принципе модель пассивного дохода к ним не применима.
Отдельно порадовало, про мега-планы по открытию сетки в 100+ ПВЗ в Череповце. Парень явно чей надо сын, и имеет весьма специфическое понятие о "заниматься бизнесом".
Если так сложно доработать 1С для связи с модульной кроссплатформенной CRM с продуманной архитектурой, то надо доработать эту самую отличную CRM. Ведь это же гораздо проще. Не надо нанимать отдел разработчиков - пара строк на питоне пишется любой ИИ-шкой через простой промпт.
Но почему-то бизнесы упорно пытаются доработать 1С, а не эти отличные модульные приложения. Вот даже странно, отчего так?
Кто это "вы"? Там где управленцы могут и ставят задачи с измеримыми показателями, проблем с автоматизацией управления не возникает.
Проблема в том, что управленцев, которые могут видят и управляют бизнесом хотя бы сопоставимо, с тем, как это делают в Revolut очень, нет, ОЧЕНЬ мало.
Система автоматизации тут вторична - автоматизируя бардак, получаем автоматизированный бардак.
В чем плюс 1Сников - что хотя бы базовый бардак типовыми решениями закрывается. Толковый консультант по 1С вполне может на уровне топ-руководителей объяснить, чем их "гениальные" решения в области учета чреваты.
Компетенции по управлению бизнесом, а уж тем более по консультированию в этой области стоят совсем других денег.
ИНН 770600861904. В бизнесе, как минимум с 1997 года. Только один из известных объектов недвижимости оценивался в 100+ миллионов рублей. Регалии, звания, награды, в т.ч. государственные. И на голубом глазу "под влиянием мошенников"...
Если сам проект еще в хранилище, то вы себе прям кучу проблем создаете. Хорошо хоть, что они все решаемы.
Может ваш пример хотя бы сагитирует уйти с хранилища в гит, это уже сильно упростит совместную разработку.
NUMA-нода это не один процессор! В одной NUMA-ноде могут быть с полсотни процессоров.
И ограничение на работы в пределах одной NUMA-ноды справедливо для одного серверного процесса. А в кластере этих процессов могут быть десятки.
Так что не совсем понятно, откуда тезис, что используется не более одного процессора на одну информационную базу.
Типовые от 1С все таки написаны довольно хорошо, и вполне могут доживать до сотен пользователей без доработок кода и архитектуры. Чего зачастую не скажешь о партнерских решениях - там временами прям сборники "как не надо делать"
Все верно, код в 1с по прежнему выполняется в один поток. На клиенте это вполне нормально - бизнес-логика там не выполняется, а переключать доступность кнопок и одного потока достаточно.
На сервере же, у каждого серверного вызова свой отдельный поток. И хотя внутри код по прежнему выполняется линейно, сервер отлично масштабируется под текущую нагрузку - потоков создается столько сколько нужно. Дальше уже потоками рулит операционка.
Если же хочется какой-то алгоритм сделать многопоточным, то велком в ад фоновых заданий.