Нельзя распечатать один и тотже документ из World дважды, или как создавать один документ группе разработчиков? Опции

[Yra]

Как сажусь в ворд писать документ - пытаюсь сделать всё поуму: выработать один стиль ля абзацев, заголовков, приложений, табуляции. Писать документ одним и темже шрифтом и др. В общем по мере разрастания документа процесс выходит из-под контроля: появляются левые стили, плывёт табуляция и т.д. А если шаблон документа создан кем-то предварительно - то это вообще вилы. А если, не дай Бог, нужно распечатать с другого компа- жди чудных открытий. Частично спасает система контроля за версиями поекта. Если докмент требует редакции нескольких человек- то туши свет. Знакома эта проблемма? Ещё приходится постоянно следить чтобы ворд не делал переносы посреди ТУ и ГОСТ. А если в дальнейшем документ придётся редактировать... Знаю, что большинству знакомы эти проблеммы... однако посмотрите на импортную документацию. Меня охватывает зависть... В общем я сделал вывод что путёвые документы можно создать в таких системах как LateX.
Однако там свои трудности: надо подобрать текстовый редактор, заточенный под скрипты LateX типа WinEdt или TeXnicCenter, разъяснить системе про переносы, растягивание слов по строке и др...
В общем может кто- нибудь дать подробное руководство по затачиванию подобной системы под наши ГОСТы для текстовой документации?

[Yra]

При правильном подходе единичной загрузке на странице проекта может соответствовать over 9000 (с стремлением к 100500) количество пользователей.

Это не тот случай.

И да, идея запихивания всех примеров в один файл мне не видится правильной.

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

Документирование самоочевидного штука дорогая не только для писателя, но и для читателя.

Раньше народ даже книги писал типа "Создание интерактивного web -сайта с нуля" - вообще то даже это не совсем очевидная вещь, много было тонких моментов.

Потому что с учётом фактического статуса ESKDX только он представляет определённый интерес.

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

Ещё Вы планировщик проектов с сетевыми графиками забыли упомянуть (типа Redmine). Я с ним разбирался раньше, кстати.

Но для этого нужно сделать очень до фига именно в части инфраструктурных вопросов.

Вот это мне и не нравится в "правильном подходе" - много бюрократии, причём исходный код - отодвирается на третий план.

Не надо валить в одну кучу рисование схем и диаграмм с явными иллюстрациями.

И как Вам рисование схем (принципиальных, к примеру) средствами LaTeX ? По мне - смахивает на мазохизм. Я пользуюсь путём PCAD -> BullzipPDF -> PDF -> включение в LaTeX. При таком подходе получается неразмыленная картинка в документе. И самое важное - легко отредактировать исходник и опять перевести в pdf.

4. Создавать репозитории (git, svn, cvs).

cvs - морально устарел.
svn -я его и юзаю, локально. Только фиксации осуществляю туда не от ревизии к ревизии, а по мере выполнения логически завершенных операций: захотел экперимент поставить - зафиксировался и дальше ковыряю весь проект. То что зафиксировал - ревизией назвать нельзя, но не фиксироваться - чревато негативными последствиями. Можно конечно заморочиться "деревом проекта", с "ветвями", со "слиянием в основную ветку".... но это попахивает раздвоением/растроением личности на данном соло-проекте.

А зачем мне оно?

На ftp много интересного есть...


Вообще Ваш подход хорош для проекта масштаба "Российская сквозная ECAD - система полностью по ЕСКД" где должна быть куча разработчиков/тестеров/администраторов/пользователей. Всё это должно двигаться в правильном направлении. В проектах такого масштаба по другому нельзя т.к. концы с концами не сведутся никогда. Мой проект простенький. Можно себе голову заморочить в ущерб основному.

Вас случаем не сохранилось резервной копии дистрибутива eskdpz?

не нашел.

[_Ⓐ_]

Это не тот случай.

Да, этот результат соответствует правильному решению.

Как раз все косяки выползают наружу при таком подходе.

Только разбирать их неудобно.
Именно поэтому проектов, где весь код, или хотя бы все тесты запихивались в один файл мне не встречалось.

Конечно, нужно сделать ещё пустой проект, чтобы начинающий его брал за основу.

Мне видится лучше шаблоны для типовых (и лично используемых) документов.

Из открытых вопросов, может быть ты встречал:
Регламентируется ли ГОСТом (и если регламентируется, то каким) размер шрифта аннотации?

Раньше народ даже книги писал типа "Создание интерактивного web -сайта с нуля" - вообще то даже это не совсем очевидная вещь, много было тонких моментов.

Потому что обработка с целью популярного переложения является одним из самых эффективных технологий самообразования (помнишь анекдот?).

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

Несомненно там не всё доделано.
Но в рамках моей практики его скорее хватает.
И, что самое главное — проект включён в архив CTAN. Причём там он висит в поддерживаемом статусе (что не вполне соответствует действительности).
И как следствие — вероятность повторения эпизода с eskdpz на порядки ниже.

Ещё Вы планировщик проектов с сетевыми графиками забыли упомянуть (типа Redmine). Я с ним разбирался раньше, кстати.

Сетевые графики для базара ИМХО скорее мешают.

Вот это мне и не нравится в "правильном подходе" - много бюрократии, причём исходный код - отодвирается на третий план.

80/20 во всей красе, с тенденцией к усугублению.
Как товарищи говорят про жабу: чтобы правильно написать программу из буквально десятка строчек нужно изучить не один талмуд.
Ну и известная задача построения графа зависимостей.
Вместе с дилеммой: пинаем upstream или городим костыли.

И как Вам рисование схем (принципиальных, к примеру) средствами LaTeX ? По мне - смахивает на мазохизм. Я пользуюсь путём PCAD -> BullzipPDF -> PDF -> включение в LaTeX. При таком подходе получается неразмыленная картинка в документе. И самое важное - легко отредактировать исходник и опять перевести в pdf.

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

cvs - морально устарел.

Апелляции к «моральному устареванию» принципиально не аргумент!

svn -я его и юзаю, локально. Только фиксации осуществляю туда не от ревизии к ревизии, а по мере выполнения логически завершенных операций: захотел экперимент поставить - зафиксировался и дальше ковыряю весь проект. То что зафиксировал - ревизией назвать нельзя, но не фиксироваться - чревато негативными последствиями. Можно конечно заморочиться "деревом проекта", с "ветвями", со "слиянием в основную ветку".... но это попахивает раздвоением/растроением личности на данном соло-проекте.

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

Вообще Ваш подход хорош для проекта масштаба "Российская сквозная ECAD - система полностью по ЕСКД" где должна быть куча разработчиков/тестеров/администраторов/пользователей. Всё это должно двигаться в правильном направлении. В проектах такого масштаба по другому нельзя т.к. концы с концами не сведутся никогда. Мой проект простенький. Можно себе голову заморочить в ущерб основному.

Не-а ☺
Мой подход — классика базара: нужно (оптимально и монистично) решение (свободное!) enterprise класса — ставим его.
В то время как проприетарщики изыскивают способы обойтись без приобретения дорогостоящих лицензий.

не нашел.

Увы.
И наглядная иллюстрация правильности пропагандируемого подхода.