«Если я вам скажу “темно как у негра в …”, вы сразу поймете о каком месте чем идет речь, даже если я не закончу фразу. Так происходит потому что в натуральном языке вероятность появления слова сильно зависит от контекста. Байесовский же классификатор представляет документ как набор слов вероятности которых условно не зависят друг от друга.»
отлично расписано!!! )))
Так и сделал :). Разбил на два корпуса. Стандартная, вобщем, практика. names.txt — файлик создавался шафлом по списку женских и мужских имен.
А в чем результат завышен?
Ниже — код для тестирования.
def test(classifier, test_set):
hits = 0
for feats, label in test_set:
if label == classify(classifier, feats):
hits += 1
return hits/len(test_set)
def get_features(sample): return (
'll: %s' % sample[-1], # get last letter
'fl: %s' % sample[1], # get first letter
'sl: %s' % sample[0], # get second letter
)
if __name__ == '__main__':
samples = (line.decode('utf-8').split() for line in open('names.txt'))
features = [(get_features(feat), label) for feat, label in samples]
train_set, test_set = features[:-100], features[-100:]
classifier = train(train_set)
print 'Accuracy: ', test(classifier, test_set)
В экосистеме PHP нет ярко выраженного лидера среди фреймворков и, грубо говоря, на каждом новом проекте есть большая вероятность встретить новый для себя фреймворк. И после изучения двух хочешь-нехочешь, но будешь понимать где фреймворк, а где язык.
> Разработчики начинают использовать Rails. Обучаются только рельсам. Не могут сделать шага без них. Не могут отличить, что является чистым Ruby, а что является рельсовым монки-патчем. Они не видят чего-то лучше этого, да и не хотят ничего лучше.
То же самое и с разработчиками на PHP-фреймворках…
Вы должны сначала создать прочную ООП конструкцию, а уже потом упрощать её с помощью DSL.
Конечно, весь мир в последние 10 лет как раз работает над упрочением ООП конструкций.
Я сначала хотел надергать очень смешных цитат, но потом решил, что тогда придется каждое предложение из заметки комментировать.
Поэтому скажу главное: если вглядеться в то, что сейчас делает Piotr Solnica, многократно цитируемый в статье, то это (сюрприз) не переход на PHP. И не переход на Node/Go/Rust/Buzz. И даже не на Elixir, который, надеюсь, постепенно вытеснит рельсы — не потому, что такой прямо ух, а потому, что запускается внутри бима. Так вот, Петр — отчаянный руби-евангелист, и приводить его тезисы против рельс (а часто — и те, кто в теме, прекрасно это знает, — лично против DHH) в качестве аргумента в пользу «руби уже не торт» — может либо очень глупый и несведущий профан, либо злонамеренный подтасовщик. Автор заметки, судя по всему, из первых.
Руби код в 20 раз лаконичнее и выразительнее подавляющего большинства современных языков. Конкуренты у него в этой области — разве что эрланг и отчасти лисп. И поэтому большинство успешных проектов, которым нужно было быстро взлететь без заметных инвестиций его выбирали. Он не лучше, не хуже, он короче.
Для высоконагруженных систем не годятся ни руби, ни пхп. Но до высокой нагрузки в 99% процентах случаев есть время и ремурс все переписать правильно.
Поэтому мне странно в сто пятьдесят первый раз читать сравнительные статьи. Это как если бы Вася опубликовал длинную статью о своей возлюбленной, а тут пришел бы Петя и стал с ним спорить: нет, моя лучше. Одинаково хороший и одинаково безобразный код можно напистаь на абсолютно любом языке программирования.
Я в свое время перешел на Rails с PHP по следующим причинам:
1. Удобство поддержки. Жестко определенная структура папок проекта, нейминга дало мне возможность не только быстро анализировать чужие коды, но и вспоминать через полгода «что ж я тут понаписал». В случае с PHP — развитие моих девелоперских навыков мешало мне понять старый код и требовало времени и усилий разобраться в нем.
2. Более чистый синтаксис. Видеть User.firstname мне гораздо приятнее и проще для восприятия чем $user->firstname()
3. Удобное из коробки разделение на среды: development, test, production
4. Очень четкая и прозрачное разделение на контроллеры, модели, виды.
Меня периодически друзья просят посмотреть MODx, сайты на Symphony, но для меня это каждый раз сильный стресс. Нет ощущения — что сейчас полезу в проект, и буду знать, где какие части найти. Ну и плюс каждый раз после такого опыта радуюсь, что имею возможность писать именно на Rails или на чистом Ruby (есть собственный framework для CLI-приложений, не использующий Rails).
Summary: еще один программист посмотрел на мир за пределами своего одного язычка и понял что Ruby ничем существенно не лучше PHP. Но в общем-то и не хуже, поэтому он не готов агитировать за переход на PHP. Если бы он посмотрел немного дальше, то обнаружил бы, что к той же группе относятся Python, Perl и всякие модные node.js.
Очень много всего в кучу собрано, немного прокомментирую.
Rails в 2016 году уже далеко не инновационный фреймворк:
1) всё самое интересное реализовали и другие (и это хорошо)
2) многим проектам на rails уже по многу лет (тому же basecamp),
тут не до экспериментов уже, скорость адаптации новых идей значительно снижается
3) веб за это время поменялся, rails зафейлил поддержку этих изменений:
3.1) веб-сокеты — поддержка заявлена, но лично у меня не взлетело за несколько дней, когда было нужно, пришлось по другому делать
3.2) api-only server side — только сейчас выпускают rails 5 с этим, но оно какое-то ущербное
3.3) микросервисы — вроде бы не мешает, но памяти есть слишком много, если дробить на микросервисы
Если хочется инновационности, то это все же в строну ECMAScript (Meteor.com например) и Golang, PHP тут не при чем.
Что все еще хорошо в rails?
1) ActiveRecord — как раз в противоположность твиту выше. Хорошо, когда можно начинать с простого (всё в одном классе), а при необходимости уже рефакторить и выделять новые классы.
2) Синтаксис руби — всё-таки он один из самых чистых/читабельных. Можно долго рассуждать про IDE, но это помогает скорее в наборе кода, а не читабельности.
3) Определенный уровень матёрости. Сейчас уже выработаны best practicies и куча библиотек, много материалов для обучения. Все руби библиотеки хорошо работают с rails, проблем в подключении нет. Проблем с поиском библиотеки под задачу не встречал.
Есть давно известные проблемы:
1) производительность ruby — они всегда были, с нулевых версий rails, но никогда особо не считалось важным
2) сложность установки — сейчас при наличии ансиблов с шефами и докерами острота снизалась
3) острота ножей — требуются лучше, чем хорошие программисты
4) добавьте свое
Приоритет рейлс — дать лучшим программистам лучший (приятный и острый) инструмент для производительной (с точки зрения фич) серверной разработки. Рейлс не подходит для «промышленной» разработки (когда команда состоит из одного регуляра и кучки юниоров). Исходя из отдельных фраз, с чем-то подобным столкнулся и автор статьи (например, не должно быть большого количества манки патчей, что-то они явно не так делали).
Раньше было практически невозможно найти программиста на php (в смысле, именно программиста), а в rails стекались лучшие из php и java. Сейчас уже не так: и в php научились программировать, и в рейлсах слишком много курсов «программист за неделю».
при всём при том, что на рубях все фреймворки умеют просто и изящно работать локально (для разработки) из коробки.
PHP сам умеет работать для разработки из коробки. php [options] -S : [-t docroot] Всё, даже фреймворки не нужны.
но в средних и больших проектах у PHP сказывается отсутствие инструментов (или их зачаточное состояние) на скорость и удобство деплоя.
capistrano, puppet — зачаточные? )
Про сервер приложений, автор вообще не особо понимая что пишет написал судя по всему…
Как я понимаю, он имел в виду, что в PHP для создания типового сервера не нужно писать ни строчки кода, серверные функции берёт на себя среда исполнения, а приложение (для разработчика) работает по CGI, а на Ruby обычным является написание сервера на Ruby или использование написанного другими типа Thin.
>В PHP модно кричать что мы реализовали AR, но там даже десятой доли того что есть в рельсах не реализовано, попробуйте выполнить подзапрос с фильтрацией в любом PHP ORM, например, подобия которых в php фреймворках нет и непонятно будут ли.
Простите, а в чем проблема? В среднестатистическом AR (для примера возьмем тот, что в Yii2) с подзапросами работать более чем удобно, любой relation легко фильтруется в анонимных функциях, просто приведу пару строк из документации:
Всё-таки видно, что пришли поспорить, а не к истине придти. Мне вам доказывать теперь, что ООП — это хорошо?) Пожалуйста, пользуйтесь чем хотите, но в мире программирования, отличии от мира реального, нет Единственной Истинной Религии, если вы своими комментариями пытаетесь претендовать на это.
Ну что же. Большой респект и автору, и переводчику, рискнувшему выставить этот перевод на публику. Респект за смелость.
То, о чем говорит автор, давно уже назрело. Просто не принято было говорить вслух. Все последние годы считалось среди программистов средней руки хорошим тоном на публику кричать «пых — говно, руби рулит!», а тем временем потихоньку пилить проекты на Wordpress и, прости господи, Битриксе ради булочки с маслом.
Руби — мёртв. И уже поздно обсуждать, как его реанимировать, нужно понять — как же это получилось? Как так вышло, что PHP, язык «быдлокодеров» внезапно (sic!) оказался более гибким, более быстрым, более правильным в архитектурном смысле, расцвел в пышную экосистему множества отличных фреймворков, а «илитный» Ruby лежит и плохо пахнет?
Имхо, анализ сводится к трем пунктам:
1. Монополия. Рельсы убили Руби. RIP они оба. И не только в рельсах дело. Дело в монополии на всё — один (фактически!) фреймворк, один человек, отвечающий за сам язык, одна система пакетов. Нет конкуренции — нет развития.
2. Отсутствие развития самого языка. И даже отсутствие внятных механизмов обсуждения такого развития! Сравните, например, переходы PHP 5 -> 5.3, 5.3->5.4, 5->7. Каждая новая версия — фактически новый язык. Что нового появилось в Ruby за те же годы? А?
3. Сильная связность с окружением. PHP работает везде, на любой ОС, с любым веб-сервером и без него, не требуя ничего от окружения, кроме возможности запустить бинарник «php.exe» (условно). А еще php-fpm.
PHP не пытается быть сервером приложений, он просто честно делает своё дело — принимает запрос, отдает ответ и умирает. Может быть пора перестать воспринимать это, как недостаток дизайна языка?
Всё вышенаписанное — имхо и не отменяет уважения к тем, кто честно делает своё дело, программируя на Ruby и рельсах.
По своему небольшому опыту взаимодействия с рельсами (а конкретно периодическое обновление redmine) могу сказать что почти любой проект на PHP гораздо легче поднять чем на рельсах — последний раз особенно доставил переезд на centos 7 — вроде и окружение очень похожее, но все равно пришлось помучиться несколько часов — bundler отказался грузить зависимости из-за конфликтов/ошибок, а гугл как обычно оказался пуст :( И это реально проблема — любую нестандартную ошибку практически невозможно нагуглить, redmine у меня где-то с 2010 наверное и я бы не сказал что стало сильно лучше (обновляю раз в год/два), разве что bundler появился, до него всё еще печальнее было...
В статье в принципе описывается взгляд с практической стороны на то что творят/пишут теоретики. Так в любой науки теоретики вычисляют коней в вакууме, пока кто то напридумает как это реализовать/применить на практике. Вы же не будете ругать людей которые всерьез обсуждают возможность заселения других планет в других солнечных системах, так как с вашей точке зрения до них нельзя долететь.
ElasticSearch? Вы серьезно? Нет я понимаю сравнивать еще Solr со Sphinx, но эластик просто по всем основным параметрам, типа скорость, гибкость настройки и т.д. просто рядом не стоял… Про масштабируемость я вообще промолчу.
При включении «просто» морфологии оно все слова приводит к одному и тому же стему внутри и более не отличает.
Можно попробовать index_exact_words=1 + expand_keywords=1. Первое сохранит исходные точные формы в индекс. Второе автоматом расширит запрос и заменит каждое слово на (=слово|слово). Что, теоретически, приведет к бусту веса точных совпадений.
Если совсем в корень копнуть, то все банально — профессионалы идут туда, где видят возможность _своего_ профессионального роста. Актуально для всех, но наиболее актуально для технарей, более склонных к узкой специализации без переключения в другие области (я не про другие языки/платформы, а другую деятельность).
Для стартапов же, на мой взгляд, еще важнее обратное следствие: такие профессионалы хороши для оптимизации — для масштабирования проекта с уже подтвержденной до деталей бизнес-моделью. А на старте нужны пусть не такие зубры, но мастера на все руки, обязательно способные не только программировать, но и общаться, без склонности к перфекционизму — даже если за ними придется потом всю начинку переделывать.
Почему так: На старте же проекта бизнес-модель на самом деле не известна, в каких бы деталях ее ни описали/ни продумали, а значит, цель — найти бизнес-модель через эксперименты: очень много неопределенности, разные виды деятельности завязаны одна на другую, разделить их сложно. В такой ситуации те профессионалы, которые фокусируются лишь на своей области, только мешают: стремятся сделать сразу хорошо свою часть, плохо понимают других участников. Это касается не только технарей, но у технарей выражено обычно сильнее в силу специфики профессии и мышления.
На сколько я знаю, «Лоцман» — коробочный продукт с преднастроенными бизнес-процессами. Изменить готовые процессы в нем не так то просто. Надо или иметь хорошие знания самого продукта, или платить денежки интеграторам. Причем денежки немалые (в одной из знакомых мне организаций на Лоцман потратили несколько миллионов, а «воз и ныне там»).
Мой жизненный опыт уже научил меня, что нет проектных организаций с одинаковыми бизнес-процессами. Каждой надо «шить на заказ». А в этом случае, нужен не коробочный продукт, а платформа с готовыми шаблонами процессов, которые изначально предполагают, что их не станут использовать «как есть», а скопируют и «допилят» под себя. Коей easla.com и является. Я свой процесс Задачи опубликовал для общего использования. Кто захочет, сможет его заимствовать и заточить под себя. Равно как и я когда-нибудь, когда пойду работать в другую организацию :)
Кстати, насчет непохожести. Есть ГОСТ 21.1101-2013, единый для всех проектных организаций. Регламентирует правила оформления проектной документации в организациях по всей России. Но даже в организациях находящихся в границах шести кварталов нашего города оформляют документацию по-разному, хотя вся она соответствует ГОСТ. Парадокс. :)
Я вам завидую изо всех сил. В моей последней организации, которую очень любят вспоминать на хабре, исключительно массовой практикой среди всех руководителей было вообще никогда принципиально не читать почту, уведомления и не отвечать на звонки. Срочные тикеты, по которым время реакции было установлено вендором в сутки, согласовывались годами, а не срочные — вообще никогда. Высшее руководство их в этом активно поддерживало, а тех, кто пытался напоминать о том, что хорошо бы всё-таки провести запланированные работы — довольно быстро изгоняли из компании.
отлично расписано!!! )))
А в чем результат завышен?
Ниже — код для тестирования.
То же самое и с разработчиками на PHP-фреймворках…
Я сначала хотел надергать очень смешных цитат, но потом решил, что тогда придется каждое предложение из заметки комментировать.
Поэтому скажу главное: если вглядеться в то, что сейчас делает Piotr Solnica, многократно цитируемый в статье, то это (сюрприз) не переход на PHP. И не переход на Node/Go/Rust/Buzz. И даже не на Elixir, который, надеюсь, постепенно вытеснит рельсы — не потому, что такой прямо ух, а потому, что запускается внутри бима. Так вот, Петр — отчаянный руби-евангелист, и приводить его тезисы против рельс (а часто — и те, кто в теме, прекрасно это знает, — лично против DHH) в качестве аргумента в пользу «руби уже не торт» — может либо очень глупый и несведущий профан, либо злонамеренный подтасовщик. Автор заметки, судя по всему, из первых.
Руби код в 20 раз лаконичнее и выразительнее подавляющего большинства современных языков. Конкуренты у него в этой области — разве что эрланг и отчасти лисп. И поэтому большинство успешных проектов, которым нужно было быстро взлететь без заметных инвестиций его выбирали. Он не лучше, не хуже, он короче.
Для высоконагруженных систем не годятся ни руби, ни пхп. Но до высокой нагрузки в 99% процентах случаев есть время и ремурс все переписать правильно.
Поэтому мне странно в сто пятьдесят первый раз читать сравнительные статьи. Это как если бы Вася опубликовал длинную статью о своей возлюбленной, а тут пришел бы Петя и стал с ним спорить: нет, моя лучше. Одинаково хороший и одинаково безобразный код можно напистаь на абсолютно любом языке программирования.
1. Удобство поддержки. Жестко определенная структура папок проекта, нейминга дало мне возможность не только быстро анализировать чужие коды, но и вспоминать через полгода «что ж я тут понаписал». В случае с PHP — развитие моих девелоперских навыков мешало мне понять старый код и требовало времени и усилий разобраться в нем.
2. Более чистый синтаксис. Видеть User.firstname мне гораздо приятнее и проще для восприятия чем $user->firstname()
3. Удобное из коробки разделение на среды: development, test, production
4. Очень четкая и прозрачное разделение на контроллеры, модели, виды.
Меня периодически друзья просят посмотреть MODx, сайты на Symphony, но для меня это каждый раз сильный стресс. Нет ощущения — что сейчас полезу в проект, и буду знать, где какие части найти. Ну и плюс каждый раз после такого опыта радуюсь, что имею возможность писать именно на Rails или на чистом Ruby (есть собственный framework для CLI-приложений, не использующий Rails).
Rails в 2016 году уже далеко не инновационный фреймворк:
1) всё самое интересное реализовали и другие (и это хорошо)
2) многим проектам на rails уже по многу лет (тому же basecamp),
тут не до экспериментов уже, скорость адаптации новых идей значительно снижается
3) веб за это время поменялся, rails зафейлил поддержку этих изменений:
3.1) веб-сокеты — поддержка заявлена, но лично у меня не взлетело за несколько дней, когда было нужно, пришлось по другому делать
3.2) api-only server side — только сейчас выпускают rails 5 с этим, но оно какое-то ущербное
3.3) микросервисы — вроде бы не мешает, но памяти есть слишком много, если дробить на микросервисы
Если хочется инновационности, то это все же в строну ECMAScript (Meteor.com например) и Golang, PHP тут не при чем.
Что все еще хорошо в rails?
1) ActiveRecord — как раз в противоположность твиту выше. Хорошо, когда можно начинать с простого (всё в одном классе), а при необходимости уже рефакторить и выделять новые классы.
2) Синтаксис руби — всё-таки он один из самых чистых/читабельных. Можно долго рассуждать про IDE, но это помогает скорее в наборе кода, а не читабельности.
3) Определенный уровень матёрости. Сейчас уже выработаны best practicies и куча библиотек, много материалов для обучения. Все руби библиотеки хорошо работают с rails, проблем в подключении нет. Проблем с поиском библиотеки под задачу не встречал.
Есть давно известные проблемы:
1) производительность ruby — они всегда были, с нулевых версий rails, но никогда особо не считалось важным
2) сложность установки — сейчас при наличии ансиблов с шефами и докерами острота снизалась
3) острота ножей — требуются лучше, чем хорошие программисты
4) добавьте свое
Приоритет рейлс — дать лучшим программистам лучший (приятный и острый) инструмент для производительной (с точки зрения фич) серверной разработки. Рейлс не подходит для «промышленной» разработки (когда команда состоит из одного регуляра и кучки юниоров). Исходя из отдельных фраз, с чем-то подобным столкнулся и автор статьи (например, не должно быть большого количества манки патчей, что-то они явно не так делали).
Раньше было практически невозможно найти программиста на php (в смысле, именно программиста), а в rails стекались лучшие из php и java. Сейчас уже не так: и в php научились программировать, и в рейлсах слишком много курсов «программист за неделю».
PHP сам умеет работать для разработки из коробки. php [options] -S : [-t docroot] Всё, даже фреймворки не нужны.
capistrano, puppet — зачаточные? )
Как я понимаю, он имел в виду, что в PHP для создания типового сервера не нужно писать ни строчки кода, серверные функции берёт на себя среда исполнения, а приложение (для разработчика) работает по CGI, а на Ruby обычным является написание сервера на Ruby или использование написанного другими типа Thin.
Простите, а в чем проблема? В среднестатистическом AR (для примера возьмем тот, что в Yii2) с подзапросами работать более чем удобно, любой relation легко фильтруется в анонимных функциях, просто приведу пару строк из документации:
$customers = Customer::find()->joinWith([
'orders' => function ($query) {
$query->andWhere(['>', 'subtotal', 100]);
},
])->all();
Всё-таки видно, что пришли поспорить, а не к истине придти. Мне вам доказывать теперь, что ООП — это хорошо?) Пожалуйста, пользуйтесь чем хотите, но в мире программирования, отличии от мира реального, нет Единственной Истинной Религии, если вы своими комментариями пытаетесь претендовать на это.
То, о чем говорит автор, давно уже назрело. Просто не принято было говорить вслух. Все последние годы считалось среди программистов средней руки хорошим тоном на публику кричать «пых — говно, руби рулит!», а тем временем потихоньку пилить проекты на Wordpress и, прости господи, Битриксе ради булочки с маслом.
Руби — мёртв. И уже поздно обсуждать, как его реанимировать, нужно понять — как же это получилось? Как так вышло, что PHP, язык «быдлокодеров» внезапно (sic!) оказался более гибким, более быстрым, более правильным в архитектурном смысле, расцвел в пышную экосистему множества отличных фреймворков, а «илитный» Ruby лежит и плохо пахнет?
Имхо, анализ сводится к трем пунктам:
1. Монополия. Рельсы убили Руби. RIP они оба. И не только в рельсах дело. Дело в монополии на всё — один (фактически!) фреймворк, один человек, отвечающий за сам язык, одна система пакетов. Нет конкуренции — нет развития.
2. Отсутствие развития самого языка. И даже отсутствие внятных механизмов обсуждения такого развития! Сравните, например, переходы PHP 5 -> 5.3, 5.3->5.4, 5->7. Каждая новая версия — фактически новый язык. Что нового появилось в Ruby за те же годы? А?
3. Сильная связность с окружением. PHP работает везде, на любой ОС, с любым веб-сервером и без него, не требуя ничего от окружения, кроме возможности запустить бинарник «php.exe» (условно). А еще php-fpm.
PHP не пытается быть сервером приложений, он просто честно делает своё дело — принимает запрос, отдает ответ и умирает. Может быть пора перестать воспринимать это, как недостаток дизайна языка?
Всё вышенаписанное — имхо и не отменяет уважения к тем, кто честно делает своё дело, программируя на Ruby и рельсах.
По своему небольшому опыту взаимодействия с рельсами (а конкретно периодическое обновление redmine) могу сказать что почти любой проект на PHP гораздо легче поднять чем на рельсах — последний раз особенно доставил переезд на centos 7 — вроде и окружение очень похожее, но все равно пришлось помучиться несколько часов — bundler отказался грузить зависимости из-за конфликтов/ошибок, а гугл как обычно оказался пуст :( И это реально проблема — любую нестандартную ошибку практически невозможно нагуглить, redmine у меня где-то с 2010 наверное и я бы не сказал что стало сильно лучше (обновляю раз в год/два), разве что bundler появился, до него всё еще печальнее было...
Можно попробовать index_exact_words=1 + expand_keywords=1. Первое сохранит исходные точные формы в индекс. Второе автоматом расширит запрос и заменит каждое слово на (=слово|слово). Что, теоретически, приведет к бусту веса точных совпадений.
Для стартапов же, на мой взгляд, еще важнее обратное следствие: такие профессионалы хороши для оптимизации — для масштабирования проекта с уже подтвержденной до деталей бизнес-моделью. А на старте нужны пусть не такие зубры, но мастера на все руки, обязательно способные не только программировать, но и общаться, без склонности к перфекционизму — даже если за ними придется потом всю начинку переделывать.
Почему так: На старте же проекта бизнес-модель на самом деле не известна, в каких бы деталях ее ни описали/ни продумали, а значит, цель — найти бизнес-модель через эксперименты: очень много неопределенности, разные виды деятельности завязаны одна на другую, разделить их сложно. В такой ситуации те профессионалы, которые фокусируются лишь на своей области, только мешают: стремятся сделать сразу хорошо свою часть, плохо понимают других участников. Это касается не только технарей, но у технарей выражено обычно сильнее в силу специфики профессии и мышления.
Мой жизненный опыт уже научил меня, что нет проектных организаций с одинаковыми бизнес-процессами. Каждой надо «шить на заказ». А в этом случае, нужен не коробочный продукт, а платформа с готовыми шаблонами процессов, которые изначально предполагают, что их не станут использовать «как есть», а скопируют и «допилят» под себя. Коей easla.com и является. Я свой процесс Задачи опубликовал для общего использования. Кто захочет, сможет его заимствовать и заточить под себя. Равно как и я когда-нибудь, когда пойду работать в другую организацию :)
Кстати, насчет непохожести. Есть ГОСТ 21.1101-2013, единый для всех проектных организаций. Регламентирует правила оформления проектной документации в организациях по всей России. Но даже в организациях находящихся в границах шести кварталов нашего города оформляют документацию по-разному, хотя вся она соответствует ГОСТ. Парадокс. :)