Comments (9)
На данный момент под крышкой hyoo-ru 65 репозиториев. Каждое приложение имеет свою репу, где название это её поддомен, что неконсистентно с шаблоном именования
mam_{some}
, который применяется в mam_lib, mam_mol, mam_hyoo.
Я думаю лучше вообще отказаться от префикса mam_
и оставить lib
, mol
, hyoo
.
Можно ли средствами mam сделать репозиторий со всеми приложениями $hyoo, и "подмешивать" в этот неймспейс модули из других репозиториев, например $hyoo_crowd? И стоит ли?
Сделать-то так не сложно и примерно так было с $mol_app
, но десятки не связанных друг с другом приложений в одном репозитории - это плохо масштабируемое решение. Сейчас проект $hyoo
демонстрирует возможности MAM
по масштабированию разработки на множество команд, каждая из которых работает со своим репозиторием.
Также, часть приложений в mol/app являются редиректами на приложения под hyoo.ru. Зачем они нужны?
Собственно, это остатки от переезда ряда приложений из зоны "демок" в зону "самостоятельных продуктов". Редиректы оставлены, чтобы внешние ссылки на эти приложения выдавали не 404, а актуальный адрес. Возможно какие-то из них или даже все уже можно безболезненно удалить - это надо с каждым разбираться отдельно.
Я хочу понять, является ли текущее состояние дел правильным, и можно ли сделать лучше.
Экосистема постоянно эволюционирует, так что тут и там можно встретить атавизмы, так что везде есть что улучшить.
Несколько недель назад я пытался предложить локализации в приложения, но, видимо, удалил свои форки раньше времени и все пулреквесты схлопнулись. А иметь и поддерживать тьму форков не хочется.
Пулреквесты можно переоткрыть же. Вообще, предлагать патчи можно и через интерфейс гитхаба не создавая у себя форков.
Также, на мой взгляд, неконсистентные имена репозиториев и сплетение приложений, ухудшают исследуемость экосистемы.
Речь о том, чтобы переименовать имена вида sketch.hyoo.ru
в hyoo_sketch
? Да, это было бы логично. Хотя сейчас можно по имени домена понять где искать его код. С другой стороны, одно приложение может быть доступно и на разных доменах.
Тут есть ещё такой нюанс: в рамках организации hyoo-ru
есть же не только MAM репозитории. И если всё именовать по mam-неймспейсам, то для них получается не останется места, ведь если их оставить, о это будет вводить в заблуждение.
from mam_mol.
Я думаю лучше вообще отказаться от префикса mam_ и оставить lib, mol, hyoo.
Например https://github.com/hyoo-ru/perf.js.hyoo.ru - он должен называться hyoo_js_perf но из-за того что автодеплой есть на гитхаб страницы надо называть по доменному имени. Причем не обязательно доменное имя будет соответствовать тому как внутри приложение называется только читая задом наперед (В этом примере оно соответствует - $hyoo_js_perf
)
В mam_
префиксе есть плюс, я однозначно знаю что речь идет о компоненте mam экосистемы. Это наоборот упрощает просмотр реп и отфильтровывать от левых не под mam сделаные репы (если такие были б). Я б хотел иметь какой-то префикс, если не мам то что-то другое.
from mam_mol.
Не, на гитхаб пейджес ссылки получаются сейчас вида https://hyoo-ru.github.io/perf.js.hyoo.ru, так что ограничений на имена особо нет.
Ну вот hyoo_
и mol_
могут быть такими префиксами.
from mam_mol.
Не пользовался гитхабпейдж, не знал.
Тогда надо ответить на вопрос, надо давать информацию где лежать проект будет и что он требует mam (иначе все это в ридми надо описывать)
Думаю название ревы по типу mam_hyoo_js_perf
лучше всего подходит.
Почему:
- Фильтрация реп, если все они будут содержат
mam_
то легко отфильтровать именно проекты которые сделаны с mam подходом - Сортировка реп! Фактически будет показано древо проектов
- Кто "в теме", тот поймет куда клонить надо, даже не читая ридми (если он самодостаточен и все зависимости уже есть в meta.tree вне этого неймспейса)
note: mam когда-то может стать отдельным проектом (например переместив mol/build/ в mam/), тогда будет mam_mam, не очень красиво. Но я не знаю как по другому указать в имени что проект сделан "под" mam.
С другой стороны имя репы https://github.com/hyoo-ru/case.hyoo.ru говорит сразу что что есть сайт, я его копирую и могу открыть. Ибо ридми @nin-jin добавлять лениться :) Если его перейменовать в mam_hyoo_case то надо создать ридми файл и вставить туда ссылку на приложение. Что считаю также ок, ридми вставлять надо всегда, иначе выглядит не серьезно и сиротой репа, тем более зачастую в приложении нету описания о чем приложение вообще, юзер, должен разгадать квест по сути, но есть зачастую иконка на исходники-гитхаб, тут бы и ридми пригодился.
В общем я за единообразие, mam_
или подобный префикс для каждого проекта
from mam_mol.
В описании каждого репозитория так-то есть ссылка на сайт.
Ещё есть такой момент: Если именовать по неймспейсу, то разные инструменты могут использовать это соглашение для автоматизации рутины. Например, можно упростить meta.tree избавив от необходимости прописывать в нём каждый репозиторий, чтобы он мог автоматически выкачиваться.
Точкой входа для пользователя всё же является не репозиторий, а сайт, а на сайте уже есть ссылки на репы.
from mam_mol.
В описании каждого репозитория так-то есть ссылка на сайт.
Возможно, но я открыл первый попавшийся, и не нашел https://github.com/hyoo-ru/case.hyoo.ru
Ещё есть такой момент: Если именовать по неймспейсу, то разные инструменты могут использовать это соглашение для автоматизации рутины. Например, можно упростить meta.tree избавив от необходимости прописывать в нём каждый репозиторий, чтобы он мог автоматически выкачиваться.
Интересная идея, но я б лучше тулзу делал для обновления meta tree нежели запросы слать к гитхабу, что б не было вендор-лок на гитхаб. Гитхаб сегодня есть, а завтра заблокируют или умрет, и потом пиши тулзу под другой гит-хостера.
А meta.tree прост, юзер знает какие еще есть репки в экосистеме пакета без использования тулзов а открыв файл редактором.
from mam_mol.
Я говорю не о вендор локе, а о такого рода записях:
pack_prefix git \https://github.com/hyoo-ru/hyoo_
from mam_mol.
About
Это и есть вендорлок, когда надо будет уехать с гитхаба, эта инфа потеряеться. Ссылку не жалко, ибо хостится на гитхабе, пропадет гитхаб, ссылка будет не актулальна, но описание пропадет. Лучше что б репа была самодостаточной.
pack_prefix git \https://github.com/hyoo-ru/hyoo_
В таком случае нельзя сказать что же доступно тебе, надо открывать ссылку, убирать перфикс, долго нудно. Изучению через исходники будет затруднительно, надо лазить на гитхаб.
Я понимаю что плюс в том что не надо будет комитить регистрацию нового компонента/приложение.
from mam_mol.
Учитывая, что хостится у нас всё на github pages, то пропажа гитхаба сделает и ссылку нерабочей.
from mam_mol.
Related Issues (20)
- Doc comments in view.tree HOT 4
- $mol_pick_time - user friendly time picker HOT 5
- Not able to use spread when destructuring object HOT 4
- mam для разработки бекенда HOT 6
- демо drag/demo не работает в мобильном браузере HOT 1
- Cache-Control: no-cache для test.html HOT 4
- $mol_attach port to $mol_gallery
- $mol_book2_demo: add descriptions
- Фейлится сборка, если в пути к папке проекта есть пробелы HOT 2
- Ссылка сливается с общим фоном инструкции HOT 1
- Bug with button showcase HOT 1
- $mol_tag_tree: automatic taxonomy by tags HOT 2
- Возможность делать снепшот документации и восстанавливать кэш браузера из нее
- На главной оставить только несколько ссылок
- $mol_date improvements HOT 1
- В viewtree не прорастают дефолтные методы из массивов, если явно не заданы в корне
- Translation license problem HOT 1
- Маркетинг слишком токсичный, идеи в фреймворке интересные. HOT 2
- Unexpected behavior of $mol_tree2_to_json HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from mam_mol.