История внедрения GNU/Linux (ООО Оптовик)

>> Ох, а слабо Валеру на Линух пересадить?

Прости, X-treme, кажется ты не тот X-treme с которым я знаком ))

Давай я завтра отпишусь и там скалькулируем, мы здесь вовсе не пальцем деланные и с майкрософтом в дёсны не целуемся.

> Давай я завтра отпишусь и там скалькулируем, мы здесь вовсе не пальцем деланные и с майкрософтом в дёсны не целуемся.

Не, давай не будем :) Если вас все устраивает -- слава Богу!

У меня своих хлопот: дипломник через 3 недели защищается :)

Нет, позвольте! После столь проникновенных речей изобличающих поганое быдло и наполненных столь пронзительными переживаниями за судьбы простых труженников села я не имею ни малейшего морального права пустить весь процесс на самотёк.

> Зато независимость от (как я понимаю, довольно хреновой) сети

Ошибаетесь, практически везде размер последней мили (от аппаратуры провайдера до адсл модема) составляет *НЕСКОЛЬКО МЕТРОВ*. Это же бывшие колхозы, там почта, телеграф, телефон, столовая и правление под одной крышей, как в прямом, так и не только в оном, смысле. Ви такие не поверите! Работает всё аки швейцарские часы. Однако здесь не внутримкадье, а регион с более низкими домами и асфальтом иной консистенции, хотя мэр действительно как в Париже. Здесь аренда каналов у провайдера для организации сети передачи данных стоит денег, а пара мегабит влёгкую реализуемая на такой последней миле всё равно не поможет в деле просасывания данных для локальной восьмёрки. Поэтому только терминалы, а уж про удобство обновления ПО и говорить незачем!

> и отчеты

Мы таки не ищем зелёных человечков и не дробим чиферы. Ещё раз хочу акцентировать внимание уважаемого доцента на том простом факте, что нам отчёты никуда не упёрлись. Нам нужна первичка -- путевые листы, наряды, лимитно-заборные ведомости, приходные и расходные ордера, графики отпусков и прогулов, кто сколько и чего сделал и сколько и чего при этом спи^Wоприходовал. Для этого и сидит там офисное животное для вноса всего этого добра в базу. Не будь компьютера и канала до головного офиса непосредственно на месте, всё это бы набивалось кем-то по бумажкам в головном офисе. А это ещё и возить надо за сто километров каждый день. Зачем? Чтобы обработать первичку у нас уже в головном офисе есть специально обученные специалисты ведущие аудит, отчётность, планирование и многое другое.

> можно послать хоть голубиной почтой (на карте памяти).

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

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

> Впрочем, ваши деньги, ваши сотрудники -- дело ваше, как бизнес организовывать.

Именно! Умничка! Дайте я Вас таки опять расцелую! Всё уже организовано именно таким образом, чтобы было максимально удобно, наименее затратно как по материальным рессурсам, человеческим, так и временным. По крайней мере на данном этапе организации. Изменятся внешние условия -- инфраструктура очень быстро отреагирует на изменение. А вот когда все весовые автоматизируем, будем первичку в рилтайм получать с минимальным человеческим фактором.

> RDP как я понимаю, здесь не ключевой момент вовсе.

Ахринеть! Честное пионерское! Да Вы просто гений! Идите ко мне работать. Мне очень нужны толковые люди.

PS: А тема дипломной-то у подопечного случайно не бухгалтерский учёт? ;)

>какой то вы абсурд говорите про M$ и 1C

>откаты имеют место там где должны, а чего должны 1C у M$

Мало ли какие у них могут быть соглашения? Правда отрицать не стану слух не подтверждённый.

>Клинт к сожалению только под Виндоус, но... месяц назад был выпущен альфа-релиз платформы 1С 8.2 в которой все компоненты существуют, как под виндоус, так и под Линукс. Окончательный релиз намечен на конец этого года.

Дай Бог чтобы всё так ибыло.

>А толку? Саппорта один фиг не будет в должном количестве... Вопрос - кто будет так оперативно Ананас допиливать?

Кто мешает Ананасу заниматься платной поддержкой?

> Кто мешает Ананасу заниматься платной поддержкой?

Никто не мешает. Ананас ей итак занимается. Можно оплатить любой каприз и получить эксклюзивный Ананас.

> > Вопрос - кто будет так оперативно Ананас допиливать?

> Вот где можно реально заработать на поддержке! Это можно как плюс расценивать.

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

> Кто мешает Ананасу заниматься платной поддержкой?

Быдломанагеры спросят "а зачем, когда есть 1ц? Оно глобально и надежно". Да и плата может быть выше, чем у 1ц, ибо клиентская база позволяет держать целое стало бадлокодеров, а у Ананаса гораздо более скромные ресурсы, а значит и денег больше стоит (ибо прибыль идет с малого количества клиентов), и реагирование дольше (людей мало).

А еще есть орда сертифицированных на каких-нибудь курсах 1С-ников

Чудненько, еще один шаг к здоровому человечеству =). Даешь Linux success stories в массы!

зы: "не вычитано" в подписи к новости исчезло - стало приятнее читать. Спасибо.

> есть орда

Орда? Где? Полгода себе в контору не можем восьмёрочника найти! Не то, чтобы вменяемых, вообще никаких нет.

В нашей дыре пално. Плюс кучка фирмочек занимающихся обслуживанием/внедрением.

А вот никсового одмина найти не можем.

> В нашей дыре пално. Плюс кучка фирмочек занимающихся обслуживанием/внедрением.

Именно восьмёрочников? Потому как здесь у нас одичавших и оголодавших семёрочников отлавливают и отстреливают регулярно.

> А вот никсового одмина найти не можем.

Махнёмся?

>Именно восьмёрочников? Потому как здесь у нас одичавших и оголодавших семёрочников отлавливают и отстреливают регулярно.

С семеркой уже мало кто дело хочет иметь, а те кто по-моложе - и не видели ее зачастую.

>Махнёмся?

Дырами?

> Нам нужна первичка -- путевые листы, наряды, лимитно-заборные ведомости, приходные и расходные ордера, графики отпусков и прогулов, кто сколько и чего сделал и сколько и чего при этом спи^Wоприходовал.

А что мешает таки использовать локально установленный тот же "ананас" (или еще что-нибудь подобное), в котором тупо набивается эта первичка и в виде отдельных файликов выкладывается на сервак - каждое удаленное рабочее место ложит на сервер в свой каталог документы с именем в виде номердокумента. Откуда автоматически всасывается в базу по факту появления файлов в каталоге (тупо по крону)? Простенько, дешевенько и со вкусом;).

Я вот думаю над таким вариантом. Правда не в силу узости канала, а в силу его дороговизны для терминалов. Пока это вообще никак не объединено.;)

> У меня своих хлопот: дипломник через 3 недели защищается :)

Студентик... И эти дети учат кого-то как жить, как работать, что такое труЪ ОС и вякают что-то про сеть и бухагалтеров...

> Нет, позвольте! После столь проникновенных речей изобличающих поганое быдло и наполненных столь пронзительными переживаниями за судьбы простых труженников села я не имею ни малейшего морального права пустить весь процесс на самотёк.

Бугага, Lumi хорош над красноглазыми детьми стебаться.

>А где найти эти патчи? Кроме тех, которые открыто выложены для древней 8.1.5?

Где найти эти патчи? 1С раздаёт со своего сайта src.rpm от своей сборки 8.2, там все патчи внутри есть. Даже пересобирается.

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

Обдуманая стратегия внедрения способна разорвать любой замкнутый круг.

> у Ананаса гораздо более скромные ресурсы, а значит и денег больше стоит (ибо прибыль идет с малого количества клиентов), и реагирование дольше (людей мало).

вы, извиняюсь, на этот Ананас вблизи смотрели? Покамест это только "заявление о намерениях". Одно-два внедрения за пару лет (последние полгода-год), не собирается под Qt4 (надо дергать порт), очень мало готовых прикладных решений -- законченных и типовых. В форуме народ всё собирается реализовывать объекты регистр и проводки, это занавес.

Такое ощущение, что visual mockup есть, ядра-то и прикладного функционала у этой учетной системы не хватает. "Всего лишь", ага.

Хотя есть мысли, что, где и как дописать :))

ЗЫ. EOL QSA (на котором в ананасе пишутся конфигурации) == декабрь 2008 года. Если Ananas не портируют на Qt4/QtScript до этого срока, можно будет тихо его сливать.

> вы, извиняюсь, на этот Ананас вблизи смотрели? Покамест это только "заявление о намерениях". Одно-два внедрения за пару лет (последние полгода-год), не собирается под Qt4 (надо дергать порт), очень мало готовых прикладных решений -- законченных и типовых. В форуме народ всё собирается реализовывать объекты регистр и проводки, это занавес.

Я имел в виду не конкретно текущее состояние Ананаса, а вообще любые потуги написания своей системы. Ананас в этой стадии уже не первый год. От бизнеспака больше пользы (сам не бухгалтер, знаю по слухам)

> Такое ощущение, что visual mockup есть, ядра-то и прикладного функционала у этой учетной системы не хватает. "Всего лишь", ага.

Ну скопировали идею конфигуратора, осталось "всего-то" конфиг дописать.

...

...

Как выше писал, была у нас такая идея, заделать свою бюзгалтерию - клиенты через веб-морду, через SSL, на сервере постгресс и перл. Ну вроде как браузеры сейчас хоть какие-то стандарты держут, поэтому не нужно будет морде скакать под qt3/qt4/gtk в случае "глобальных" обновлений. Для понту взяли ExtJS - кнопочки/рамочки красивые. Для всего подходит - кнопочки на формочках визуально рисуются, шаблончики документиков создаются. Сервсайд генерит сложные выборки, хотя основное назначение - IO-данных. Вот и готов конфигуратор. А толку...

Есть такие "хорошие" приложения как 2ндфл (аки коммерческий "Налогоплательщик" в виде триала) и халявный "Налогоплательщик ЮЛ". Ну и еще всякий мусор, вроде пенсионного фонда. Чем они писаны - неизвестно. И хотя я даже видел зачатки скинов (очень полезная фича в бухгалтерии), но общий уровень софта на "тут у меня сынок накропал прогу, вот в ней и сдавайте". Причем аналогов нету, формат файлов обмена нигде не регламентирован. В лучшем случае CSV с неизвестными столбцами.

Дык вот, в этих "хороших" приложениях народ работал не один год. И в них накопились базы. Причем не только в них, но и в 1ц, там есть похожие таблицы, но не полная совместимость - некоторых полей нехватает. И в один прекрасный день что-то там обновилось, надо было обновить софт и сделать отчетик на 300 рыл. Конечно, на выполнение работы есть 2 дня, причем "до 12:00 сдать, потом штрафы". Дело простое - из старого выгружаем, а в новом генерим. Причем генерим в рульном XML с русскими тегами. Ага. Из старого вроде бы выгрузилось. А вот в новый оно не загружается. Говорит "формата такого не разумею или фаза луны не та". И все. Чего ей надо, чего ей не по душе - хз. Конвертилка бы в принципе и не нужна, но главбуху уже под 50, набивку отчета на 300 рыл за ночь никак ниасилит. Что же делать? Я бы написал свою конвертилку (уже морально был готов), надо было только входной формат узнать. Поехали в налоговую. Главный программист - блондинко, которая жжот болванки с налогоплательщиком всем приходящим. К удивлению, она не испугалась слова "иксемель". К счастью, этот отчетик кто-то уже сдал, поэтому мне дали "подсмотреть" "правильный" файл, предупредив, что это опупенно секретная информация. Это оказался XML с русскими тегами и своим доктайпом. А в том файле, что был у нас сгенерен, небыло этого доктайпа. К счастью, все решилось копированием первых 10 строк из "правильного" отчета в свой отчет. Таки сдали. И за 500км ехать не пришлось, что таки не редкость.

...

...

Дык вот... Свой конфигуратор слепить - это дело недели. Все есть. Платформа в виде браузера, куча фреймверков типа ExtJS, рисовалка кнопок пишется за пару дней... На JS программить легко. От сервсайда по началу требуются только примитивные функции IO. А вот как подумаешь о хотя бы импорте данных из других софтин, так дурно становится. Какие тут нафиг спецификации, на пальцах бы хоть кто-то объяснил. Генерить XML с русскими тегами - я даже перловую библиотеку допилить согласен. Вот только сегодня одна структура, а завтра "крутой программист на делфи" что-то переделает и мне тоже все переделывать.

И подумалось мне... Нет, не осилит дорогу идущий, ибо стадо тут нужно... Причем стадо быдлокодеров - пишущих хоть коряво, но быстро, и даже не думающих о оптимизации. Ибо если задумаются, то это затраты времени. Ибо отчеты надо сдавать завтра. А как посмотришь на отчетики в "налогоплательщике юл" на 50 страниц мелкого шрифта, так и желание этим заниматься пропадает вовсе. Вот и с Ананасом скорее всего так. И ему подобными.

>Я имел в виду не конкретно текущее состояние Ананаса, а вообще любые потуги написания своей системы. Ананас в этой стадии уже не первый год. От бизнеспака больше пользы (сам не бухгалтер, знаю по слухам)

wtf из бизнеспака? где посмотреть?

>Ну скопировали идею конфигуратора, осталось "всего-то" конфиг дописать.

угу, и в таком вот недопиленном состоянии почти все "свои учётные системы". Если брать аналоги 1Cv7, есть свободные вечно недопиленные 2C gpl (форк, оригинал форка закрылся, сдох -- осилили ядро и интерпретатор, конфигуратор, на MFC), Qt1L (переписали 2C на Qt, но ниасилили ничего кроме конфигуратора), Ananas (переписали на Qt 3, прикрутили QSA QtScript, ниасилили базовые объекты и свой предметный язык ) и довольно симпатичные коммерческие аналоги с совместимым по 1С входным языком (или мощнее по возможностям) : CБиС++ (язык 1Сv7), Матрица:Предприятие(трехзвёнка, сервер приложений, версионник, "преведно-ориентированный языг", сдох, автор открыл сайты знакомств -- ппц короче), ещё что-то можно накопать.

У всех есть типа свой уникальный конгениальный фреймворк, ядро(в запущенных случаях и ядра нет), нет предметного языка и решений на нём. Если есть язык, он как правило свой. Хотя если бы сделали входной язык 1С (V7,V8,etc), единое ядро и подключение других, более удобных языков/API -- можно было бы "просто" заменить платформу исполнения языка 1С на другую, получить сразу работающий прототип, потом померять в своём фирменном профилировщике узкие места и переписать их на своём гениальном API. Только то что нужно, только узкие места.

Есть ещё 1L, R2D2, Дебет++, и т.п. -- но у них свой входной язык, и совсем другая песня. Тоже довольно сыро по готовым конфигурациям. Так что довольно убого всё и выбирать особо не из чего.

>надо было только входной формат узнать. Поехали в налоговую. Главный программист - блондинко, которая жжот болванки с налогоплательщиком всем приходящим. К удивлению, она не испугалась слова "иксемель". К счастью, этот отчетик кто-то уже сдал, поэтому мне дали "подсмотреть" "правильный" файл, предупредив, что это опупенно секретная информация. Это оказался XML с русскими тегами и своим доктайпом. А в том файле, что был у нас сгенерен, небыло этого доктайпа. К счастью, все решилось копированием первых 10 строк из "правильного" отчета в свой отчет. Таки сдали. И за 500км ехать не пришлось, что таки не редкость.

ппц какая душещипательная история, ога. XML с русскими тегами -- это CommerceML, описаный в доках и на сайте у 1С? У него и схема есть, доступна. Нет бы посмотреть на сайте и написать простой внятный XSLT.

Нет, Леонид, 8.2.5 мне не актуально, а вот сырца с 8.2.6-1С2 я не видел, хотя может сейчас выложили, месяц уже к ним не заходил.

>Дык вот... Свой конфигуратор слепить - это дело недели. Все есть. Платформа в виде браузера, куча фреймверков типа ExtJS, рисовалка кнопок пишется за пару дней... На JS программить легко. От сервсайда по началу требуются только примитивные функции IO.

посмотрите R2D2, кажется. Там сервер приложений на клиппере, клиент -- XUL Firefox.

>Вот только сегодня одна структура, а завтра "крутой программист на делфи" что-то переделает и мне тоже все переделывать.

в 1Сv7 например, XML используется для загрузки-выгрузки между непохожими конфигурациями (разной структурой, схемой БД, когда например реквизит из шапки документа в одной конфиге становится реквизитом в табличной части или связанном справочнике в другой конфиге). XML стандартного, типового вида (CommerceML, ЕМНИП) универсально сопостовляет такие конфиги, генерится автоматически из третьей конфигурации "конвертация данных". Похожая фигня используется для миграции данных с 1Cv7 в 1Cv8.

Так что ваша страшная проблема уже решена, и не раз. Другое дело, что небыстро оно работает на XML, но если это критично, можно по XML схеме составить DTS скрипт для MSSQL и грузить им.

>Нет, не осилит дорогу идущий, ибо стадо тут нужно... Причем стадо быдлокодеров - пишущих хоть коряво, но быстро, и даже не думающих о оптимизации. Ибо если задумаются, то это затраты времени. Ибо отчеты надо сдавать завтра.

это да. Я пару лет сталкивался с "гениальными конфигурациями" на 1С, от v6,v7.5, v7.7 до v8. Это write-only код, смысл своих локальных доработок в двух словах можно свести к минимальным доработкам "чужого кода". Лепим костыль сверху-сбоку, потому что при след. "обновлении" апстрима в след. квартал наши изменения затрутся и придётся иметь геморой со сливанием изменений, тестированием (что сломали в апстриме). Поэтому лучшая в сопровождении конфига -- та, где меньше всего меняется в основном коде.

Притом механизмов толком удобных нет. Можно прикрутить снаружи mercurial, багтрекинг, тестирование вручную. Но останемся при врождённой кривости "базовой платформы" и входящем быдлокоде (который, однако, закрывает какую-то проблему).

Вон код ядра Linux переписывался несколько раз. Патчи по 10 Мб, связанные множественные изменения, выкидывание deprecated api вроде rlocate. В 1С никто на это не пойдёт, никто не пойдёт на то, чтобы радикально усовершенствовать платформу. Они становятся заложниками своего быдлокода из "обновлений" и заложниками своей платформы, как в MS.

>как посмотришь на отчетики в "налогоплательщике юл" на 50 страниц мелкого шрифта, так и желание этим заниматься пропадает вовсе. Вот и с Ананасом скорее всего так. И ему подобными.

ну дело это нудное, но жутко интересное. Например, интересно сервер приложений на лиспе, ядро на лиспе, декларативные транзакции и транслятор с входного языка 1С в конфигуратор от ананаса воткнуть. Чтобы automagically заработал уже написанный в 1С быдлокод. И сделать несколько DSL на эту задачу, императивный 1С быдлокод, Ъ декларативный язык на лиспе, интеграция с профилировщиком на предмет узких мест -- и всё из единой модели, трансформациями одного и того же быдлокода, как референсной спецификации :))

>"вот новый указ, вот ссылка, там скачайте новые формочки". Льем формочки (ворд, иксель), бухи матерятся, но переделывают. Я конечно не знаю как на нормальных предприятиях, но на "государственных" оно именно там. Причем они только поменяют, а сдавать надо уже завтра. Вопрос - кто будет так оперативно Ананас допиливать?

В Ananas'е с этим проще, чем в 1С. Качаем формы ворд/иксель, открываем в опеноффисе, вставляем команды для макроподстановки -- и опа, готовые формы. Или конвертируем doc в odt, достаем XML из ZIP, автоматически мёржим изменения между новой и старой версией XML-я типа git --rebase (или hg merge). Или можно XSLT написать. А в 1С формочки ручками переделывать каждый раз, ога.

>восьмёрки, регулярно оная курочится на предмет ошибок и изменений -- раз в неделю уж точно, но бывает и по три раза на дню. Посчитайте сколько мне нужно напрячь эникеев, дабы поддерживать конфигурации в синхронном состоянии в локальных базах удалённых точек, не говоря уж и про то, что уважаемый доцент не имеет ни малейшего понятия как лицензируется сама восьмёрка и раздаются ключи в сетке, но при этом высказывает советы астрономической глупости. Да, я в курсе, что "распределённые базы данных" это сейчас очень модно, практически нанотехнологии современного православного ИТ... И каждый хочет ни к месту блеснуть своей причастностью к сакральному знанию.

чё их там напрягать, "поддерживать конфигурации в синхронном состоянии в локальных базах удалённых точек". Настроил правила обмена, автообмен, синхронизировался обновлениями -- конфигурация на клиентах и обновилась. Если на клиентах она не дорабатывалась, никакого геммороя нет, ни с обычной распределёнкой в v7 ни с нормальными решениями вроде МОД в v7 или планов обмена в v8.

>Если есть желание почитать, могу выразить несколько мыслей по поводу когда именно распределёнка с планами обмена актуальна и при каких условиях и затратах она действительно будет функционировать.

ну если тебе критично, чтобы за время пока производство/склад что-то ввёл в базу, бухгалтер тут же это увидел сразу -- тогда да. А если он может работать по "вчерашним" данным -- тогда нет.Условия действительно есть, надо миграцию данных настроить. Но в МОД или в v8 с этим проблем нет, можно сделать всё, что угодно. Да и то закрываются периоды, делается 2 базы -- для отчетов и для работы, вчерашняя и сегодняшняя, устанавливаются разумные правила обмена. И сэкономить на лицензиях не получится, ога (хотя потратишься на трафике).

>>откаты имеют место там где должны, а чего должны 1C у M$

одно время MSSQL из комплекта 1Cv7 SQL+MSSQL стоил дешевле, чем MSSQL отдельно. Но потом кажется они разругались, MS прекращает поддержку MSSQL2000 (и эту халяву для MSSQL2000), с чем и связан переход на PostgreSQL. ХЗ на каких условиях они эту скидку выбили.

> wtf из бизнеспака? где посмотреть?

http://www.pvision.ru/bp.htm, вроде оно. Никогда не пользовался.

> Если есть язык, он как правило свой. Хотя если бы сделали входной язык 1С (V7,V8,etc), единое ядро и подключение других, более удобных языков/API

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

> ппц какая душещипательная история, ога. XML с русскими тегами -- это CommerceML, описаный в доках и на сайте у 1С?

Вах! Теперь я знаю как эта гадость зовется. Вопрос - если оно сгенерилось через попу, то как опознать хотя бы имя трупа? Прилагавшийся ман читал, ничего похожего на описалово небыло. И самое главное, ЕМНИП плевалась как раз не 1ц, а прога налоговой... Маны для которой надо искать на сайте 1ц... Гениально.

> XML стандартного, типового вида (CommerceML, ЕМНИП) универсально сопостовляет такие конфиги, генерится автоматически из третьей конфигурации "конвертация данных". Похожая фигня используется для миграции данных с 1Cv7 в 1Cv8.

Когда оно появилось? Я уже пару лет на 1ц не смотрел, мне воспоминаний до сих пор хватает. Его всякие "пенсионный фонд.exe" умеют?

> Они становятся заложниками своего быдлокода из "обновлений" и заложниками своей платформы, как в MS.

Зато позволяет плюнуть на них и сделать свое. Но в перспективе. Или даже в мечтах.

> В Ananas'е с этим проще, чем в 1С. Качаем формы ворд/иксель, открываем в опеноффисе, вставляем команды для макроподстановки -- и опа, готовые формы. Или конвертируем doc в odt, достаем XML из ZIP, автоматически мёржим изменения между новой и старой версией XML-я типа git --rebase (или hg merge). Или можно XSLT написать. А в 1С формочки ручками переделывать каждый раз, ога.

Повтори это какому-то буху/обслуживающему эникейщегу. Открыть то файлик он осилит, а вот дальше... Дальше будут домагаться программистов, которые занимаются совершенно другими делами. Наблюдал забавное зрелище, как блондинки осваивали шаблоны и макросы... Проще пристрелить и сделать самому.

Да и сработает только в том случае, если форму изменили незначительно, а вот если там 3 десятка новых полей, десяток из которых - результат выборок - вот тут уже потрахаешься, изменением шаблона не отделаешься.

> Да и сработает только в том случае, если форму изменили незначительно, а вот если там 3 десятка новых полей, десяток из которых - результат выборок - вот тут уже потрахаешься, изменением шаблона не отделаешься.

Ну мне проще добавить три десятка новых полей, чем добавить те же самые три десятка новых полей и перепахивать форму, подгоняя ее под размеры страницы, значения и пр. Готовая форма - это минимум полдела. ;)

> чё их там напрягать, "поддерживать конфигурации в синхронном состоянии в локальных базах удалённых точек". Настроил правила обмена, автообмен, синхронизировался обновлениями -- конфигурация на клиентах и обновилась. Если на клиентах она не дорабатывалась, никакого геммороя нет, ни с обычной распределёнкой в v7 ни с нормальными решениями вроде МОД в v7 или планов обмена в v8.

В теории всё красиво. На практике же конкретно в нашем случае совершенно ненужный геморой и лишние напряги. У нас не та топология рабочих мест, при которой применение РБД хоть как-то оправдано. Не говоря о необходимости иметь N филиальных лицензий и выросшей в N раз стоимости разработки и сопровождения сторонних модулей. Да и работать в терминальной сессии намного комфортнее в восьмёрке, чем локально. Запуск -- 2-3 секунды, исполнение запросов в 2-5 раз быстрее, чем в файловом варианте. К тому же в точке такие машинки, которые восьмёрку кхм... не потянут. Всё ж мы не пальцем деланные и за полтора года обдумали и перепробовали все позы и размеры и остановились на той, которая приносит минимум неудобства и затрат в сочетании с максимумом удовольствия.

Да, ещё. За трафик мы не платим. Мы платим абонентку за полосу. Гонять почту, джаббер и rdp -- того что есть за глаза.

От автора проекта: Без согласия руководителя предприятия никто и никогда ничего нигде не внедрит, не то что Linux, но даже и Windows. Тк вот. Попробуйте, если не верите.

Для Microsoft это тоже успех…?

captcha: boxfees

>Без согласия руководителя предприятия никто и никогда ничего нигде не внедрит, не то что Linux, но даже и Windows.

Брехня. Руководителю предприятия все равно какая ос :-)

>А зачем изобретать велосипед? Взять любой скриптовый язык. Чем тотже Js, на котором ананас работает, не угодил?

на эту тему писать можно долго и нудно/интересно. Начиная с изолированности и сериализации транзакций в "сервере приложений": в терминах скриптового языка (возьмём, например, язык 1С), на котором пишутся транзакции (проведение документов, чтение данных для формирования отчёта) -- в терминах скриптового языка предметной области отсутсвует такая "мелочь", как возможность указать зависимости/инварианты транзакции, какие данные она изменяет и от каких данных зависит.

Ну например, по идее, Прих.Накладная не зависит от Расходной Накл. И по идее, их можно было бы проводить параллельно, квазиодновременно.

Но:

1. может считаться средняя себестоимость по партии в РН (что само по себе зло, среднюю с/с надо считать в закрытии месяца)

2. РН и ПН могут быть по разными группам товара, но в языке это не определить, поэтому всё равно придётся блокировать всё

3. документ может изменить всё что угодно, поэтому возникает giant lock на уровне всей базы

4. Другой юзер может в это время формировать отчет по этим товарам что в РН/ПН. И отчет станет невалидным, половина отчета -- по одним данным, половина -- по другим (или возникнет ненужная блокировка на чтение) -- потому что средствами языка не определить, что входные данные, по которым формируется отчет, изменились

5. Нету параллельных (одновременных) повторяющихся процессов, как класса. Есть фиксация отдельных этапов документами.

6. Нельзя расширить модель данных.

А на уровне языка вроде "скрипта 1С" или JS как в Ананасе -- эти зависимости/инварианты указать нельзя. В v8 можно указать, что проведение док-та изменяет только указанные регистры, но это не то -- нужны нормальные замыкания. Потому что один док может изменять другие регистры, от которых зависит другой док, и потребуется "перепроводить" всю эту связанную цепочку.

Если бы скрипты писать на какой-то функциональщине и явно описать "хинты" серверу приложений (вот тут у нас инвариант по данным разных транзакций, а вот тут -- цепочка/один процесс, и надо отслеживать замыкания) -- "движок" может получить больше информации о том, какие транзакции можно параллелить, а какие выполнять обязательно последовательно. Плюс можно лениво что-то вычислять в отчетах (например, если в отчете записана "ленивая" зависимость, и требуется что-то перепровести из цепочки чтобы посчитать корректные итоги. При формировании отчета определить, что требуется перепроведение, перепровести и выдать в отчет. Хотя такой костыль как "граница последовательности" наверно совсем не нужен при грамотном проектировании, с учетом процессов).

А в Ананасе всё ещё печальнее, поскольку DSL-я там толком нет (в смысле предметной области), а есть прямое дёрганье объектной модели скриптового движка, завязано на конкретную реализацию.

>Когда оно появилось?

году в 2002-м где-то

>Его всякие "пенсионный фонд.exe" умеют?

когда я пару лет назад смотрел ЕМНИП "Налогоплательщик-ЮЛ", там печатались отчеты через MSIE, XSLT трансформацией выходного XMLя, который на дискету записывался. Схема на ссылку там где-то была, вроде бы.

>Зато позволяет плюнуть на них и сделать свое. Но в перспективе. Или даже в мечтах.

угу. И поддерживать потом самому :) Лучше делать в 2 этапа, на первом выполнять чужой код, на втором его переписать/отрефакторить в узких местах.

>Да и сработает только в том случае, если форму изменили незначительно, а вот если там 3 десятка новых полей, десяток из которых - результат выборок - вот тут уже потрахаешься, изменением шаблона не отделаешься. anonymous (*

ну как бы от сложности изменений зависит. Если мержить автоматом получается ("просто добавили ортогональные новые поля") -- всё просто, если старый код переписывается и новый на него сильно завязан -- надо сливать изменения вручную (или рефакторить шаблон для пущей ортогональности в будущем). Вообще git --rebase в 80% справляется сам.