{"id":20439452,"url":"https://github.com/softspiders/softspiders","last_synced_at":"2026-03-19T15:50:26.191Z","repository":{"id":126029788,"uuid":"169698102","full_name":"softspiders/softspiders","owner":"softspiders","description":"Main repository containing main documents","archived":false,"fork":false,"pushed_at":"2024-01-08T10:20:14.000Z","size":2204,"stargazers_count":2,"open_issues_count":1,"forks_count":0,"subscribers_count":1,"default_branch":"master","last_synced_at":"2025-09-03T23:45:25.250Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/softspiders.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE","code_of_conduct":"CODE_OF_CONDUCT.md","threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2019-02-08T07:17:10.000Z","updated_at":"2023-02-11T14:52:56.000Z","dependencies_parsed_at":"2024-01-08T11:53:26.752Z","dependency_job_id":null,"html_url":"https://github.com/softspiders/softspiders","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/softspiders/softspiders","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/softspiders%2Fsoftspiders","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/softspiders%2Fsoftspiders/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/softspiders%2Fsoftspiders/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/softspiders%2Fsoftspiders/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/softspiders","download_url":"https://codeload.github.com/softspiders/softspiders/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/softspiders%2Fsoftspiders/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":29487397,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-02-15T15:33:17.885Z","status":"ssl_error","status_checked_at":"2026-02-15T15:32:53.698Z","response_time":118,"last_error":"SSL_read: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-11-15T09:17:29.366Z","updated_at":"2026-02-15T19:03:36.683Z","avatar_url":"https://github.com/softspiders.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"# *[Проект SoftSpiders](https://github.com/softspider)*\n\n\u003cp align=\"center\"\u003e\n  \u003ca href=\"https://github.com/softspider\"\u003e\n    \u003cimg src=\"./images/sslogo-from-github-40.png\" /\u003e\n  \u003c/a\u003e\n\u003c/p\u003e\n\n## Оглавление\n1. [Предназначение](#предназначение) \n    1. [В чём проблема](#в-чём-проблема)\n    2. [Быстрое прототипирование прототипов](#Быстрое-прототипирование-прототипов)\n    3. [Классификатор *SoftSpiders*](#классификатор-softspiders)\n    4. [Прототипы *SoftSpiders*](#прототипы-softspiders)\n    5. [Классификатор программных решений](#классификатор-программных-решений)\n    6. [Сопутствующие задачи](#сопутствующие-задачи)\n2. [Принципы организации *SoftSpiders*](#принципы-организации-softspiders)\n    1. [С чего начинается разработка](#с-чего-начинается-разработка) \n    2. [Зачем нужна минималистичность](#зачем-нужна-минималистичность) \n    3. [Иерархия минималистичных прототипов](#иерархия-минималистичных-прототипов) \n3. [Иерархия прототипов](#иерархия-прототипов)\n    1. [*Свойства* и *теги*](#свойства-и-теги) \n    2. [DAG-иерархия](#dag-иерархия) \n    3. [Если кратко](#если-кратко) \n    4. [Пример](#пример) \n    5. [Текущая реализация](#текущая-реализация) \n4. [Базовые сценарии](#базовые-сценарии)\n    1. [Поиск прототипа](#поиск-прототипа) \n    2. [Создание прототипа](#создание-прототипа) \n    3. [Декомпозиция сложного прототипа](#декомпозиция-сложного-прототипа) \n    4. [Создание тега-свойства](#создание-тега-свойства) \n5. [FAQ](#faq)\n    1. [Какие проблемы решает *SoftSpiders*?](#какие-проблемы-решает-softspiders-) \n    2. [Зачем нужны прототипы?](#зачем-нужны-прототипы-) \n    3. [Почему недостаточно библиотек?](#почему-недостаточно-библиотек-) \n    4. [Сохраняется ли авторство у разработчиков прототипов ?](#сохраняется-ли-авторство-у-разработчиков-прототипов-) \n    5. [На каких технологиях реализован проект ?](#на-каких-технологиях-реализован-проект-) \n    6. [Предполагается ли платное использование сервиса ?](#предполагается-ли-платное-использование-сервиса-) \n    7. [Что делать, если у зависимостей изменяются версии ?](#что-делать-если-у-зависимостей-изменяются-версии-) \n6. [Словарь используемых тегов](#словарь-используемых-тегов)\n    1. [Правила именования тегов](#правила-именования-тегов) \n    2. [Теги-синонимы](#теги---синонимы) \n    3. [Зависимости тегов](#зависимости-тегов) \n    4. [Эффективные наборы тегов](#эффективные-наборы-тегов) \n    5. [Пояснения к тегам](#пояснения-к-тегам) \n7. [Текущее состояние проекта](#текущее-состояние-проекта)\n    1. [Эволюция и перспективы проекта](#эволюция-и-перспективы-проекта) \n    2. [Что нужно прямо сейчас](#что-нужно-прямо-сейчас) \n    3. [Что потребуется в ближайшее время](#что-потребуется-в-ближайшее-время) \n8. [Приложения](#приложения)\n    1. [Правила разработки прототипа](#правила-разработки-прототипа) \n    2. [Правила оформления README](#правила-оформления-readme) \n\n---\n\n# Предназначение \n\nЕсли кратко, *[SoftSpiders](https://github.com/softspider)* можно охарактеризовать как проект создания **классификатора\nпрограммных решений**, создаваемого разработчиками для разработчиков.  \n\n## В чём проблема \n\nПоиск качественного прототипа - программного решения, которое можно было бы использовать в качестве основы для новой\nразработки является непростой задачей, к тому же она не всегда завершается успехом.  \n\nЧем больше свойств, которыми прототип должен обладать, тем больше его сложность и тем меньше шансов его найти в готовом\nдля использования виде.\n\nСегодня для разработчика, который ищет подходящую основу для начала разработки, почти все пути ведут в\n[GitHub](https://github.com/), с появлением которого задача нахождения программного кода с нужными свойствами\nзначительно упростилась.    \nНо и в этом случае вся совокупность необходимых действий: работа с поисковиком, проверка качества исходников и\nработоспособности программ до сих пор требует немалых навыков и усилий, которые к тому же очень часто оказываются\nнеблагодарными.\n\nГлавная задача проекта *SoftSpiders* заключается в попытке решения этой проблемы.  \n\n## Быстрое прототипирование прототипов \n\n### Быстрое прототипирование\n\nПредназначение *SoftSpiders* во многом состоит в том, чтобы хорошие прототипы можно было легко находить, сравнивать,\nвыбирать и использовать по назначению, ускоряя и удешевляя создание разнообразных программных продуктов.  \nИ с этой точки зрения *SoftSpiders* можно формально позиционировать как **средство быстрого прототипирования**.\n\n### Прототипирование прототипов \n\nНо в отличие от многих других средств прототипирования *SoftSpiders* характерен тем, что его главной задачей является не\nстолько генерация готовых программ (хотя она тоже может решаться), сколько систематизация уже существующих прототипов и -\nна преемственной основе - **упрощение процесса создания самих прототипов**, что делает его своеобразным ***средством\nпрототипирования прототипов***.\n\nОсновой систематизации прототипов служит классификатор *SoftSpiders*. \n\n## Классификатор *SoftSpiders*\n\nДля лучшего понимания механизмов организации классификатора *SoftSpiders*, сразу стоит отметить, что его содержательными\nединицами (далее по тексту - элементами) не обязательно должны быть прототипы.\n\n### Не обязательно прототипы\n\n*Элементом классификатора *SoftSpiders* может быть любой набор текстовых файлов, если этому набору можно сопоставить\nкакое-то подмножество из **общего множества свойств**.*\n\nНапример, элементами классификатора могут быть:\n\n- шаблоны текстовых документов\n- кулинарные рецепты (ингредиенты могут выступать свойствами)\n- заготовки учебных (и других) планов\n- заготовки различных сценариев\n- ...\n\n**Общее множество свойств** является систематизирующей основой классификатора. Оно определяет границы, в которых будут\nсуществовать его содержательные элементы.\n\nНо при всех имеющихся возможностях классифицировать разное сам проект *SoftSpiders* ориентирован прежде всего на\nсистематизацию *программных прототипов*, на создание сервисов, упрощающих жизнь разработчиков программ.\n\n## Прототипы *SoftSpiders*\n\nКакие виды прототипов поддерживает проект ?\n\n### Программные прототипы\n\nВ *SoftSpiders* предполагается поддежка следующих видов программных прототипов:\n\n- проекты-стартеры\n- шаблоны (исходники для разнообразных генераторов)\n- образовательные проекты - проекты, используемые для обучения/самообучения\n- архитектурные решения (шаблоны проектирования, ...)\n- алгоритмы\n- конфигурации (Webpack, pom, package.json, Travis CI, Docker, ...)\n- раскладки (layout) экранов пользовательского интерфейса\n- ...\n\n## Классификатор программных решений\n\nКлассификатор *SoftSpiders* организован как иерархия прототипов, которая снабжена средствами создания, поиска и\nнавигации по иерархии прототипов.\n\nНиже по тексту иерархию *SoftSpiders* будем сокращённо называть ***SS-иерархией***, а прототипы *SoftSpiders* -\n***SS-прототипами***.\n\nПредполагается, что эта база должна охватывать все виды программной разработки без каких бы то ни было ограничений.\n\n## Сопутствующие задачи \n\nСреди задач, которые призван решать *SoftSpiders*, можно выделить ещё, как минимум, те, что направлены на обеспечение\nобмена опытом между разработчиками: \n- помощь при самообучении\n- фиксация результатов самообучения или результатов разработки в виде новых проектов\n- передача знаний при обучении (иерархия качественных программных проектов представляет собой практически готовый\nучебный материал)\n\n---\n\n# Принципы организации *SoftSpiders*\n\nДалее о том, почему содержание *SoftSpiders* составляют минималистичные программные проекты и о принципах организации\nклассификатора.\n \n## С чего начинается разработка\n\nС появлением поисковиков и открытых программных репозиториев начало нового проекта всё чаще начинается с поиска готовой\nи наиболее подходящей работающей программы-прототипа, которую можно было бы взять в качестве основы для дальнейшей\nразработки.           \n\nДля того, чтобы прототип наилучшим образом подходил в качестве такой основы, в нём не должно быть ничего лишнего -\nтолько необходимое.  \n\n## Зачем нужна минималистичность\n\nВажным и очень желательным свойством прототипа является его ***минималистичность***, поскольку она гарантирует прототипу\nсбалансированное присутствие в нём всех его свойств, упрощает пользователям-разработчикам знакомство с этим прототипом,\nупрощает сравнение его с другими, родственными прототипами, в том числе при помощи diff-инструментов, особенно, если они\nтоже минималистичны.\n\n## Иерархия минималистичных прототипов\n\nВ основе *SoftSpiders* лежит классификатор (далее по тексту - *SS-классификатор*), элементами которого являются\nпрототипы программ.\n\nПри множественном наследовании SS-иерархия может иметь множество корней. В корнях этой иерархии  лежат простейшие\nпрограммы, являющиеся hello-world-программами в самом обычном смысле этого слова: hello-world на Java, hello-world на\nJavaScript, и т.д.    \nНа следующих уровнях иерархии находятся хоть и более сложные, но, если их рассматривать в контексте свойств своих\nпредков, тоже минималистичные программы.\n\nКаждый дочерний проект-прототип добавляет к родительскому прототипу в общем случае несколько новых свойств (в идеале -\nодно), например, логирование, сборку,  тестирование, и т.п. Этот дочерний прототип, в свою очередь, становится\nродительским для других новых прототипов. И так далее.\n  \nТаким образом в результате выстраивается ***иерархия минималистичных прототипов с поддержкой множественного наследования\nсвойств***\n([DAG](https://ru.wikipedia.org/wiki/%D0%9E%D1%80%D0%B8%D0%B5%D0%BD%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D1%8B%D0%B9_%D0%B0%D1%86%D0%B8%D0%BA%D0%BB%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B9_%D0%B3%D1%80%D0%B0%D1%84)-иерархия).\n\n---\n\n# Иерархия прототипов\n\nSS-иерархия выглядит примерно так же, как иерархия классов или интерфейсов в ООП, с поддержкой множественного\nнаследования.\n\n## *Свойства* и *теги*\n\nКлючевым понятием SS-классификатора является понятие *свойства*.\n\nВ *SoftSpiders* поддерживается расширяемый стандартизованный перечень ***свойств***.\nКаждое *свойство*, как правило, определяет некоторую функциональность - то, для чего на английском обычно используется\nтермин *feature*.\n\nКаждому свойству ставится в соответствие уникальный ***тег*** (или множество *тегов-синонимов*), идентифицирующий\nэто свойство.\n\nВ контексте *SoftSpiders* понятия *тег* и *свойство* часто взаимозаменяемы. Но есть разница.  \nВ отличие от именования тегов для именования свойств не существует каких-то строгих правил - могут использоваться разные\nязыки, алфавиты, и т.п.\n\n## DAG-иерархия\n\nКаждый SS-прототип имеет какой-то определённый набор свойств и помечается соответствующим набором тегов.\n\nПоскольку не все наборы свойств могут быть сравнимы между собой, то SS-прототипы образуют\n[*частично-упорядоченное множество*](https://ru.wikipedia.org/wiki/%D0%A7%D0%B0%D1%81%D1%82%D0%B8%D1%87%D0%BD%D0%BE_%D1%83%D0%BF%D0%BE%D1%80%D1%8F%D0%B4%D0%BE%D1%87%D0%B5%D0%BD%D0%BD%D0%BE%D0%B5_%D0%BC%D0%BD%D0%BE%D0%B6%D0%B5%D1%81%D1%82%D0%B2%D0%BE),\nили [DAG](https://ru.wikipedia.org/wiki/%D0%9E%D1%80%D0%B8%D0%B5%D0%BD%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D1%8B%D0%B9_%D0%B0%D1%86%D0%B8%D0%BA%D0%BB%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B9_%D0%B3%D1%80%D0%B0%D1%84)-иерархию.\n\n## Если кратко\n\n*Каждый SS-прототип помечается соответствующим ему набором тегов. Поэтому иерархия SS-прототипов фактически является\nиерархией наборов тегов*.\n\n## Пример\n\nЛучше один раз увидеть, чем сто раз услышать.\n\nРассмотрим простой пример, иллюстрирующий возникновение отношений родитель-потомок между прототипами, в котором также\nпоказывается образование иерархии с множественным наследованием свойств.\n\nПусть прототип **A** представлен hello-world-программой на Java. Поскольку других свойств прототип **A** не имеет, то он\nпомечается только тегом *java* (набором тегов *{java}*):  \n\n\u003cp align=\"center\"\u003e \n\u003cimg src=\"./images/SimpleHierarhy-java-log4j-maven-1.png\"\u003e\n\u003c/p\u003e\n\nПусть прототип **B** отличается от прототипа **A** только тем, что он реализован по стандартам *Maven*. В соответствии с\nэтим он помечается набором тегов *{java, maven}*:\n\n\u003cp align=\"center\"\u003e \n\u003cimg src=\"./images/SimpleHierarhy-java-log4j-maven-2.1.png\"\u003e\n\u003c/p\u003e\n\nПоскольку множество тегов прототипа **A** (*{java}*) принадлежит множеству тегов прототипа **B** (*{java, maven}*),\nпрототип **B** является потомком прототипа **A**.\n\nПо-другому можно сказать, что прототип *B* функционально расширяет прототип *A*, поскольку имеет более полный набор\nсвойств.\n\nПусть ещё один прототип **C** отличается от прототипа **A** только тем, что вывод сообщений выполняется в нём с помощью\nбиблиотеки *log4j*, и в соответствии с этим он помечается набором тегов *{java, log4j}*:\n\n\u003cp align=\"center\"\u003e \n\u003cimg src=\"./images/SimpleHierarhy-java-log4j-maven-2.2.png\"\u003e\n\u003c/p\u003e\n\nПоскольку множество тегов прототипа **A** (*{java}*) принадлежит множеству тегов прототипа **C** (*{java, log4j}*),\nпрототип **C** также, как и **B**, является потомком прототипа **A**.\n\nПусть реализован ещё один hello-world-прототип на Java, назовём его **D**.  \nПусть он так же, как **B**, организован по стандарту\n*Maven* и, так же, как **C**, выводит сообщения с помощью библиотеки *log4j*.  \nТогда в соответствии со своим набором свойств прототип **D** помечается набором тегов *{java, log4j, maven}* и согласно\nвышеуказанным правилам наследования будет одновременно являться непосредственным потомком как прототипа **B**, так и\nпрототипа **C**.\n\n\u003cp align=\"center\"\u003e \n\u003cimg src=\"./images/SimpleHierarhy-java-log4j-maven-full.png\"\u003e\n\u003c/p\u003e\n\n\nВ результате прототипы **A**, **B**, **C** и **D** образуют небольшую DAG-иерархию, в которой прототип **D** является\nмножественным наследником свойств прототипов **B** и **C**.\n\n## Текущая реализация\n\nНа данный момент SS-иерархия предварительно реализована при помощи http-ссылок, размещающихся в файлах *README.md*\nсоответствующих git-репозиториев.  \n\nПо факту все git-репозитории находятся на *GitHub*. Пока это рекомендуемая практика, хотя она и не является обязательной. \n\n---\n\n# Базовые сценарии\n\nРассмотрим базовые сценарии работы с прототипами. К ним относятся:\n- Поиск прототипа\n- Создание прототипа\n- Декомпозиция сложного прототипа\n- Создание свойства\n\n### Поиск прототипа\n\nПоиск нужного прототипа происходит путём комбинирования фильтрации по тегам и дальнейшей навигации по SS-иерархии.\n\nЗамечание: в текущей предварительной реализации используется нестрогая фильтрация на основе тегов GitHub.\n\n#### Фильтрация по тегам\n\nSS-иерархия обеспечивает возможность фильтрации прототипов с помощью тегов, что позволяет, варьируя наборы тегов-свойств,\nоперативно изучать пространство имеющихся прототипов, после чего делать на этой основе быстрый и качественный выбор. \n\n#### Навигация по SS-иерархии\n\nПри навигации по SS-иерархии пользователь переходит по иерархическим связям с одного прототипа на другой, имея при этом\nвозможность подробного просмотра свойств, параметров, исходного кода и других деталей каждого из прототипов.\n \nПри навигации по иерархии предполагается, что в каждый момент времени пользователь находится на каком-то одном из её\nузлов. При этом в общем случае пользователь имеет возможность перейти или на один из узлов потомков, или на один из\nродительских узлов. \n\nВ целевой реализации навигация по SS-иерархии предполагает поддержку со стороны соответствующей клиентской программы.    \nНо в сегодняшней предварительной реализации навигация выполняется при помощи браузера посредством переходов по\nhttp-ссылкам Readme-документов прототипов, размещённых на GitHub. \n\n### Создание прототипа\n\nСоздание прототипа предполагает следующие этапы:\n\n1. Создание для прототипа git-репозитория (на данный момент рекомендуется использовать GitHub)\n2. Разработка прототипа в созданном репозитории согласно несложным [правилам](#правила-разработки-прототипа)\n3. Документирование прототипа в файле *README.md* согласно соответствующим\n[правилам](#правила-оформления-readme)\n\n### Декомпозиция сложного прототипа\n\nДекомпозиция хорошего сложного прототипа на более простые - самый удобный и лучший способ создания прототипов, поскольку,\nво-первых, разбирать проект на части гораздо легче, чем собирать, а во-вторых, в результате декомпозиции можно легко\nполучить целое семейство проектов, связанных между собой не только общими свойствами, но и **общим кодом**, что даёт\nвозможность удобо сравнивать код прототипов diff-инструментами.\n\n### Создание тега-свойства\n\n1. Перед тем, как создавать новый тег-свойство, необходимо убедиться, что этот тег отсутствует в\n[словаре](#словарь-тегов).  \nПри этом необходимо понять, действительно ли речь идёт о добавлении нового свойства или требуется добавить просто новый\nсиноним к одному из существующих тегов-свойств.   \n2. После того, как необходимость создания нового тега/синонима подтвердилась, нужно подать заявку на расширение словаря\nтегов простым письмом на адрес \u003csftspider@gmail.com\u003e в письменно-свободной форме (пока так).\n3. Дождаться необходимых изменений в [словаре тегов](#словарь-тегов) или отказа с объяснением причин, если заявку\nневозможно удовлетворить.  \n\n---\n\n# FAQ\n\n## Какие проблемы решает *SoftSpiders* ?\n\n*SoftSpiders* не решает каких-то фундаментальных проблем, но он упрощает жизнь разработчиков в таких аспектах, как:\n- старт новых проектов, предлагая удобные средства поиска качественных прототипов\n- создание новых прототипов - во многом за счёт их иерархической организации, что даёт возможность **инкрементальной\nразработки** прототипов путём создания новых на основе старых, уже присутствующих в иерархии \n- обучение новым технологиям, предлагая классификатор прототипов как хорошую систематизацию учебных материалов\n- фиксацию результатов самообучения/разработки в виде новых прототипов\n\n## Зачем нужны прототипы ?\n\nВ первую очередь прототипы нужны для разработки.  \n\nРазработку любого проекта намного проще начать, если взять за основу близкий по функциональности другой, уже работающий\nпроект. Прототипы *SoftSpiders* как раз и являются такими работающими проектами.\n\nНо помимо помощи разработчику прототипы *SoftSpiders* играют также и образовательную роль (см. выше).\n\n## Почему недостаточно библиотек ?\n\nВ мире программирования библиотеки являются неоценимым способом повторного использования программных решений. Но при\nэтом они всё же не могут удовлетворить всех потребностей, возникающих при разработке. \n\nПо сравнению с библиотеками прототипы предлагают хотя и другой, может быть менее формализованный, но в определённом\nсмысле, более высокий уровень повторного использования.\n\n### Прототипы предлагают целостные решения\n\nВ отличие от библиотек, программные прототипы представлены **работающими программами** и предлагают **целостные\nрешения**, что приципиально важно.\n\n### Качественные стартеры предлагают хорошие практики\n  \nВ частности, если говорить о библиотеках, прототипы показывают, как именно нужно использовать те или иные библиотеки,\nкак правильно их конфигурировать, как правильно совмещать версии разных библиотек и т.д. \n\n## Сохраняется ли авторство у разработчиков прототипов ?\n\nДа, в разделах описания прототипа присутствует поле *Authors*.\n\n## На каких технологиях реализован проект ?\n\nВ данный момент SS-иерархия реализована на основе git-репозиториев, размещаемых на *GitHub*. Каждый репозиторий содержит\nровно один SS-прототип. Ирархические отношения прототипов реализованы при помощи http-ссылок, размещаемых в их\nreadme-документах.\n\n## Предполагается ли платное использование сервиса ?\n\nСам по себе сервис *SoftSpider* предполагает бесплатное использование.\n\nСуществующие на данный момент прототипы разработаны под лицензией MIT и находятся в открытом доступе.\n\nВ то же время на разработчиков прототипов в *SoftSpiders* не накладывается каких-либо лицензионных ограничений.  \nПрототипы могут разрабатываться под любой лицезией, могут быть приватными (см. ниже), могут распространяться как на\nбесплатной, так и на платной основе.\n\n### Приватные прототипы\n\nОпределённая категория прототипов может быть закрыта для бесплатного доступа. \nПредполагается, что к таким прототипам доступ будет возможен только обладателями специальных учётных записей. \n\nПолитика доступа к приватным прототипам пока не определена.\n\n#### Открытые ссылки на приватные прототипы\n\nЗакрытие репозиториев приватных прототипов не обязательно относится к ссылкам на эти прототипы из других репозиториев.    \nТак например, если открытый прототип имеет ссылку на закрытый прототип-потомок, то эта ссылка может оставаться видимой.\n\n## Что делать, если у зависимостей изменяются версии ?\n\nКаждый прототип создаётся на каком-то определённом наборе библиотек, фреймворков и прочих зависимостей, версии которых\nтак или иначе фиксируются в его исходных конфигурационных файлах (pom.xml, package.json, ...).\nЕсли у зависимостей прототипа появляются новые версии, то необязательно что-то предпринимать, поскольку прототип и на\nстарых версиях продолжает сохранять своё главное качество - служить основой для других разработок.  \nВ то же время актуализация прототипа путём поддержки новых версий, конечно, приветствуется. \n\nВ случае, если при появлении новых версий у прототипа появляются новые свойства, возможны дополнительные варианты:\n- поддержка новых версий с расширением набора свойств прототипа \n- создание прототипа-потомка, поддерживающего новый расширенный набор свойств   \n\n---\n\n# Словарь используемых тегов\n\nПроект *SoftSpiders* имеет собственный  [**словарь тегов**](SoftSpiderTags.md#словарь-тегов), используемых при разметке\nпрототипов.\n  \nНиже приводятся основные правила организации работы с тегами. \n\n## Правила именования тегов\n\nПри именовании тегов можно использовать только строчные буквы латинского алфавита, знак дефиса и цифры, причём имена\nтегов должны начинаться с буквы.\n\nВ дальнейшем возможны некоторые из этих правил могут быть ослаблены.  \n\n\n## Теги - синонимы\n\nВ скобках словаря тегов указаны теги-синонимы, которые являются его полноценными элементами.\n\n## Зависимости тегов\n\nСтрелками '-\u003e' в *словаре тегов* обозначаются *теги-зависимости*. Использование зависимостей позволяет сокращать\nразметку прототипов.    \nТо есть, если, например есть в словаре тегов есть зависимости\n\n```\njersey -\u003e java, rest\nrest -\u003e api, http\n``` \n\n, то наличие в разметке узла SS-иерархии тега *rest* означает одновременное наличие там тегов *api, http*, а наличие\nтега *jersey* означает одновременное наличие там тегов *java, rest, api, http*.  \nПоэтому вместо подразумеваемого полного - **эффективного набора тегов** (см. ниже) *jersey, java, rest, api, http* при разметке прототипов можно и даже рекомендуется использовать только *jersey*.\n\n##  Эффективные наборы тегов\n\nПри построении SS-иерархии учитываются ***эффективные наборы тегов*** - те наборы, которые определяются с учётом всех, в\nтом числе транзитивных зависимостей.\n\nГраф зависимостей тегов не должен иметь циклов. Поэтому иерархия зависимостей тегов, также как и SS-иерархия, является\nDAG-иерархией.\n\n## Пояснения к тегам\n\nИмена некоторых тегов могут требовать расшифровки или пояснения. Для этого в словаре используются двоеточия.\n\nНапример, смысл тега *hapi* в контексте *словаря тегов* поясняется таким образом: \n\n```\nhapi -\u003e api, backend, node: небольшой фреймворк, использующийся для разработки web-приложений на NodeJS \n```\n\nСтоит отметить, что здесь поясняется именно *hapi*, а не его теги-зависимости: *api, backend, node*.\n\n## Изменяемость словаря\n\nСловарь тегов *SoftSpiders* является изменяемым, как правило, в сторону расширения. Изменения словаря выполняются\nучастниками проекта.\n\n---\n\n# Текущее состояние проекта\n\nВ настоящее время *SoftSpiders* находится в переходном состоянии от прототипа к MVP.\n\n*SoftSpiders* имеет несколько проектов-стартеров, некоторые из которых уже сейчас используются сторонними разработчиками.\nТо, что их пока немного, объясняется тем, что до сих пор рост SS-иерархии за редкими исключениями происходил в режиме\nproof-of-concept, снизу-вверх, что, разумеется, приводило к преимущественному росту её нижних, базовых уровней.\n\nПрограммная поддержка, автоматизирующая процессы работы с прототипами планируется, но её пока нет, если к таковой\nне относить используемые возможности GitHub: хостинг SS-репозиториев, поисковик GitHub, организацию связей между\nпрототипами через ссылки README.md и т.п.\n\n## Эволюция и перспективы проекта\n\nНаполнение базы знаний проекта продолжается.  \nОчевидно, что чем выше будет уровень  SS-иерархии, тем большим набором\nсвойств и большей сложностью будут обладать прототипы, тем большей будет стоимость добавления новых свойств, поскольку с\nростом числа используемых инструментов будет расти и стоимость решения проблем их совместимости.\nА значит - тем большую ценность решения *SoftSpiders* будут иметь для разработчиков.\n\n## Что нужно прямо сейчас\n\n- Разработка правил для участников проекта - раздела типа\n[How to Contribute](https://reactjs.org/docs/how-to-contribute.html), но пока попроще \n- Разработка манифеста проекта\n\n## Что потребуется в ближайшее время\n\n- Разработка json-представления для прототипов\n- Сайт проекта (в основе статический), который бы включал, как минимум:\n  - Систему навигации по SS-иерархии\n- Система мотивации участников\n    - геймификация\n    - рейтинги разработчиков\n    - рейтинги прототипов\n    - ...\n\n### Что будет нужно всегда ?\n\nНаполнение базы знаний прототипами - её главным содержанием\n\n---\n\n# Приложения\n\n## Правила разработки прототипа\n\nВ целом прототип разрабатывается как обычный проект. Он может быть написан с нуля, может быть fork-ом или копией\nдругого проекта. В двух последних случаях в README проекта указывается ссылка на оригинальное авторство.\n\n### Английский язык\n\nПоскольку проект *SoftSpiders* ориентирован на привлечение широкого круга участников, в том числе зарубежных, все тексты\nрепозитория SS-прототипа (код, комментарии в коде, комментарии коммитов, документация прототипа и т.п.) разрабатываются\nна английском.\n\n### Главный документ\n\nГлавный документ SS-прототипа находится в файле README.md, правила оформления которого описаны\n[здесь](#правила-оформления-документа-readmemd-ss-прототипа).\n\n\n### Автотесты\n\nКрайне желательным свойством прототипа является покрытие его кода автотестами. Впоследствии для отдельных категорий\nпрототипов наличие автотестов может стать обязательным.  \n\nПотребность в наличии автотестов обусловлена перспективами развития проекта *SoftSpiders*. Чем дальше он будет\nразвиваться, тем сложнее будут становиться прототипы, тем труднее будет вручную проверять их работоспособность,\nособенно, если поток запросов на включение прототипа в SS-классификатор будет большим.\n\nНу и, разумеется, никто не отменял связь между наличием автотестов и качеством программных проектов. В частности, для \nпрототипов-стартеров автотесты всегда являются существенным плюсом.\n\n#### Подключение средств Continuous Integration\n\nЕщё более ценным свойством проекта является *ci* - подключение средств *Continuous Integration* для автоматического\nзапуска тестов при поступлении изменений (коммитов) в репозиторий проекта.\n\nНа GitHub *Continuous Integration* поддерживается средствами [*Travis CI*](https://travis-ci.com/) и\n[*GitHub Actions*](https://github.com/features/actions).\n\n## Правила оформления README\n\nФайл *README.md*, находящийся в корневой директории репозитория, является его главным документом.  \nОн оформляется в синтаксисе markdown (желательно на диалекте GitHub).\n\n### Разделы главного документа\n\nНиже перечисляются правила оформления наиболее часто использующихся разделов README в синтаксисе markdown - в том\nпорядке, в каком они должны следовать в самом документе.\n\nРазделы, названия которых ниже по тексту помечены звёздочками, являются обязательными для указания в README проекта. \n\n\n#### Первая строка - принадлежность к *SoftSpiders* *\n\nПризнаком принадлежности репозитория к проекту *SoftSpiders* является наличие строки *'SOFTSPIDERS'* в начале первой\nстроки файла *README.md*, как здесь:\n\n```\nSOFTSPIDERS\n...\n```\n\n#### Название проекта *\n\nНазвание проекта указывается в заголовоке markdown первого уровня:\n\n```\n# rest-api-java-jersey\n```\n\n#### Раздел *Feature tags* *\n\nОписывает набор тегов-свойств прототипа, например:\n\n```\n## Feature tags\n\n- hooks\n- react\n- test\n```\n\n#### Раздел *Authors* *\n\nВ разделе перечисляются авторы прототипа с указанием распределения ролей, если это нужно, например:\n\n```\n## Authors\n\n* [Dennis Kortsch](https://github.com/DennisKo) - original code\n* [Alexander Lapygin](https://github.com/AlexanderLapygin) - catching in [Soft Spiders Net](https://github.com/softspider)\n\n```\n\n#### Раздел *Inspired by*\n\nПри желании автор может перечислить источники, вдохновившие его на создание проекта. Например:\n\n```\n## Inspired by\n\n[An Apollo Server \u0026 Client in a yarn Workspace deployed with Zeit 2.0](https://github.com/DennisKo/zeit-now-next-apollo-typescript-example)\n```\n\n\n#### Раздел *Direct ancestors*\n\nВ разделе перечисляются, если они есть, ссылки на непосредственные проекты-предки SS-иерархии. Например:\n\n```\n## Direct ancestors\n\n- [Minimal Next in TypeScript](https://github.com/softspider/next-typescript)\n- [Zeit Now \"HelloWorld\" example](https://github.com/softspider/now)\n```\n\nЕсли у проекта нет предков, раздел не включается в документ.\n\n#### Раздел *Direct descendants*\n\nВ разделе перечисляются, если они есть, ссылки на непосредственные проекты-потомки SS-иерархии. Например:\n\n```\n## Direct descendants\n\n- [Minimal Next in TypeScript](https://github.com/softspider/next-typescript)\n- [Zeit Now \"HelloWorld\" example](https://github.com/softspider/now)\n```\n\nЕсли у проекта нет потомков, раздел не включается в документ.\n\n#### Раздел *Requirements*\n\nВ разделе перечисляются программные инструменты, которые должны быть установлены на компьютере разработчика, для того,\nчтобы с проектом можно было работать. При этом указываются только те зависимости, которые не подключаются средствами\nсборки самого проекта (npm, maven, gradle, ...). Например:\n\n```\n\n## Requirements\n\n* [*Java 7*](https://www.oracle.com/technetwork/java/javase/downloads/java-archive-downloads-javase7-521261.html)\n* [*Apache Maven*](https://maven.apache.org/)\n* Some servlet container for deploying and running: [*Apache Tomcat*](http://tomcat.apache.org/), [*Jetty*](https://www.eclipse.org/jetty/), ...\n\n```\n\n#### Раздел *Install*\n\nВ разделе указывается команда, которую необходимо выполнить для подключения зависимостей проекта. Например:\n\n```\n## Install\n\n'''\nyarn\n'''\n```\n\n#### Раздел *Run test*\n\nПри наличии в прототипе автотестов, в нём указывается команда, которую необходимо выполнить для их запуска. Например:\n\n```\n## Run test\n\n'''\nyarn test\n'''\n```\n\n#### Раздел *Run*\n\nВ разделе указывается команда, которую необходимо выполнить для запуска прототипа.\nНапример:\n\n```\n## Run\n\n'''\nyarn start\n'''\n```\n\n#### Раздел *Useful materials*\n\nПеречисляются ссылки на материалы, которые могут быть полезными для знакомства со свойствами проекта.\n\n\n#### Раздел *License*\n\n### License\n\nLicensed under the [MIT license](LICENSE).\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fsoftspiders%2Fsoftspiders","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fsoftspiders%2Fsoftspiders","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fsoftspiders%2Fsoftspiders/lists"}