Форуми / National / Russian / Идеи / Github интеграция.

12>>>

esclkm
#1 05.09.2014 13:09

 

Я считаю важным оптимизацию существующих инструментов. И необходимым использование более сильных сред для этого.

Тема 1.

Быстрое добавление (публикация) плагинов. Идея взята от сих: http://plugins.jquery.com/docs/publish/ . Описание: публикация плагина на гитхубе – и перенос его в модули котонти посредством добавления ссылки.

 

Тема 2. Навеяно: https://github.com/onlinerby/onliner-b2b-api .

Создание и ведение документациии по котонти сразу на гитхубе. Позволит быстрее и четче координировать ведение документации.

littledev.ru - мой маленький зарождающийся блог о котонти.
снижение стоимости программирования и снижение стоимости производства разные вещи. Первое можно скорее сравнить с раздачей работникам дешевых инструментов, чем со снижением зарплаты
Macik
#2 05.09.2014 13:16
#39798 esclkm:

Тема 1.

Быстрое добавление (публикация) плагинов. Идея взята от сих: http://plugins.jquery.com/docs/publish/ . Описание: публикация плагина на гитхубе – и перенос его в модули котонти посредством добавления ссылки.

Не совсем понял, что предлагается — установка плагина с гитхаба на сайт пользователя, или дублирование плагина с гитхаба в репозиторий плагинов на Cotonti.com ?

Тема 2. Навеяно: https://github.com/onlinerby/onliner-b2b-api .

Создание и ведение документациии по котонти сразу на гитхубе. Позволит быстрее и четче координировать ведение документации.

Дополню, что можно на cotonti.com сделать просмотр доков с гитхаба в нашем дизайне, с понятным оглавлением, и переключением языков.

 

https://github.com/macik
правильный хостинг — https://goo.gl/fjCa1F
esclkm
#3 05.09.2014 13:21

дублирование... установка... там требует написание полноценного защищенного фтп модуля

 

Естественно... с просмотром на котонти ком.Не надо путешествовать человека

littledev.ru - мой маленький зарождающийся блог о котонти.
снижение стоимости программирования и снижение стоимости производства разные вещи. Первое можно скорее сравнить с раздачей работникам дешевых инструментов, чем со снижением зарплаты
Macik
#4 05.09.2014 13:40

По п.2 вижу такой план действий —

  • выбрать исходный формат (предлагаю markdown)
  • разработать структуру каталогов (т.е. определить как будут формироваться и распределяться по файлам разделы/подразделы/статьи). Структура должна быть понятна интуитивно и проста для навигации через ГитХаб. 
  • определить где хранить иллюстрации.
  • решить, что будем делать с текстами текущих комментариев к страницам (если таковые есть и полезны для общественности)
  • сделать тест — перенести какую-либо статью, посмотреть все ли форматирование можно уместить в формат MD и структуры каталогов.
  • Определить объем переносимой информации (например надо ли указывать авторство, как сейчас)
  • сделать автоматизацию конвертации и переноса текущей документации на гитхаб (могу взяться)
  • определить функции и основные моменты реализации плагина для просмотра дкументации на страницах cotonti.com — использовать ли хуки гитхаба для обновления инфы, как кешировать
  • определить что делаем с комментариями: будем ли оставлять комментарии и как их реализовать, как сейчас или ссылкой на соотв. ветку форума, еще что-то.

Что я забыл? 

 

Добавлено 1 минуты спустя:

зы. Тема номер 2 на мой взгляд сейчас гораздо актуальнее первой.

https://github.com/macik
правильный хостинг — https://goo.gl/fjCa1F
esclkm
#5 05.09.2014 13:43

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

есть еще вопросы:

1. индексация

2. мультилэнг.

littledev.ru - мой маленький зарождающийся блог о котонти.
снижение стоимости программирования и снижение стоимости производства разные вещи. Первое можно скорее сравнить с раздачей работникам дешевых инструментов, чем со снижением зарплаты
Dayver
#6 05.09.2014 15:26

Считаю тему 1 критически нужной в реализации (если кто то раздумывает за что перевее взятся). На равне с ранее обсуждаемой возможностью правки хотя бы слотов в админке (Если они станут более гибкими чем сейчас), загрузка расширений в ней же станет огромным шагом в повышении качества юзабилити админкой. Админку нада развивать.

Добавлено 39 минуты спустя:

Для ясности скажу что Тикет как раз в духе первой темы

Pavlo Tkachenko aka Dayver

Відредаговано: Dayver (05.09.2014 16:06, 9 років тому)
Macik
#7 05.09.2014 16:11
#39802 esclkm:

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

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

есть еще вопросы:

1. индексация

Что имеешь в виду? Поисковики, кеш страниц или возможность поиска по сайту? 

2. мультилэнг.

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

 

#39803 Dayver:

Считаю тему 1 критически нужной в реализации (если кто то раздумывает за что перевее взятся). На равне с ранее обсуждаемой возможностью правки хотя бы слотов в админке (Если они станут более гибкими чем сейчас), загрузка расширений в ней же станет огромным шагом в повышении качества юзабилити админкой. Админку нада развивать.

Пока о загрузке расширений через админку речи не идет. Это очень объемная тема. И тянет за собой кучу пока не решенных проблем, начиная о безопасной записи файлов и заканчивая темой стандартизации расширений (в том числе JS библиотек) и контроля их версий и зависимостей.
Что касается слотов, то с вводом чанком в запланированном объеме решит эту проблему.
 

 

 

https://github.com/macik
правильный хостинг — https://goo.gl/fjCa1F
esclkm
#8 05.09.2014 16:54

1. я имею ввиду текущая документация по идеее более или менее заиндексирована.... поисковиками.... а значит адреса должны сохраниться....

2. поиск по сайту должен искать в документации

littledev.ru - мой маленький зарождающийся блог о котонти.
снижение стоимости программирования и снижение стоимости производства разные вещи. Первое можно скорее сравнить с раздачей работникам дешевых инструментов, чем со снижением зарплаты
Macik
#9 05.09.2014 21:50
#39805 esclkm:

1. я имею ввиду текущая документация по идеее более или менее заиндексирована.... поисковиками.... а значит адреса должны сохраниться....

не вижу проблем — сейчас у каждой страницы свой адрес docs/…/…  
Делаем плагин с адресом /docs/ а остальная строка будет указывать на конкретный файл (дока из которого была раньше по этому адресу). 

2. поиск по сайту должен искать в документации

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

 

https://github.com/macik
правильный хостинг — https://goo.gl/fjCa1F
esclkm
#10 06.09.2014 08:23

У гитхуба есть вот такой вот сервис: https://help.github.com/categories/20/articles

Цель моего плагина: добавить возможность добавлять плагины сюда http://www.cotonti.com/extensions/ просто скормив ссылку на гитхубе.

Но! если я солью ссылку на просто репозиторий - он дожен написать ошибку!

Он должен Прочитать файл setup - из которого понять: название плагина, его версию, его описание, версию котонти и категорию.

!но тут есть грабли: у меня setup файл лежит в корне, а у траста он обычно лежит в подпапкеб какие еще способы могут быть? что надо предусмпотреть?

Дальше: как добавлять темы?

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

 

==================================================================================

 

твой плагин.

понятно, что он должнет иметь древовидную структуру.

понятно что должны быть различные файлы для разных языков.

понятно что по умолчанию будет синтаксис MD (но вот проблема : подсветка кода на разных языках программиования)

Как мы будем определять описание и название каждого каталога?

например 

docs/

docs/start/ - где и как взять описание и текст данной папки? на разных языках? снова read me файлы? 

docs/admin/

 

 

Добавлено 3 часа спустя:

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

Відредаговано: esclkm (06.09.2014 11:29, 9 років тому)
Macik
#11 06.09.2014 18:11
#39809 esclkm:

У гитхуба есть вот такой вот сервис: https://help.github.com/categories/20/articles

Ты про GitHub pages? Хочешь параллельно с отображением на сайте Котонти еще компилить доки и выкладывать на GHP?

Цель моего плагина: добавить возможность добавлять плагины сюда http://www.cotonti.com/extensions/ просто скормив ссылку на гитхубе.

Это понятно.

Но! если я солью ссылку на просто репозиторий - он дожен написать ошибку!

Он должен Прочитать файл setup - из которого понять: название плагина, его версию, его описание, версию котонти и категорию.

!но тут есть грабли: у меня setup файл лежит в корне, а у траста он обычно лежит в подпапкеб какие еще способы могут быть?

Да. Должен парсить всю структуру каталого репозитория.

что надо предусмпотреть?

Например, Варианты, когда кто-то засунул 2 плагина в репозиторий .

Еще надо извлекать файлы (README.md, README_ru.md, …) и на их основе делать страницы описания.

Дальше: как добавлять темы?

Отдельная, емкая тема. На вскидку — искать файлы theme.php там есть теги описание BEGIN_COT_THEME. Темы как правило ледат в отдельной папке по названию темы.

Можно подумать о едином файле описания загружаемых ресурсов Кота (типа composer.json) — плаг/модуль/тема/JS библиотека (в перспективе). Правда это еще одна сущность, но зато добавит четкости.

Еще надо подумать о расширении описания тем, на предмет ссылки на файл(ы) «скриншотов» темы.

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

См. выше. Я для себя давно принял такой формат.

==================================================================================

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

понятно что по умолчанию будет синтаксис MD (но вот проблема : подсветка кода на разных языках программиования)

А в чем тут именно проблема? поясни.

Как мы будем определять описание и название каждого каталога?

например 

docs/

docs/start/ - где и как взять описание и текст данной папки? на разных языках? снова read me файлы? 

docs/admin/

Можно взять какойлибо стандарт. Например ГитБук. Они для этих целей используют файл SUMMARY.md, для языковых версий поддиректории (см. описание).

Или как прикрепить картинки? Куда и как их лить, видео, ссылку на демо

Редактирование доков будет через гитхаб, так? Значит все иллюстрации мы льем в отдельный каталог (например assets, как в ГитБук). В MD прекрасно вставляются ссылки на иллюстрации. Со ссылками на сторонний контент как обычно, как и сейчас, это просто ссылки на сторонний контент. Хочешь залей на cotonti.com и дай ссылку туда.  Что касается видео — аналогично (залей на видео зостинг, дай ссылку).

 

https://github.com/macik
правильный хостинг — https://goo.gl/fjCa1F
esclkm
#12 07.09.2014 20:26

 Именя файлов - я больше за сильн котонти: README.ru.md

про гитхаб пэйдзэс я если честно не совсем знаю, что это такое.

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

и где будут храниться сязанные изображения?

 

 

 

littledev.ru - мой маленький зарождающийся блог о котонти.
снижение стоимости программирования и снижение стоимости производства разные вещи. Первое можно скорее сравнить с раздачей работникам дешевых инструментов, чем со снижением зарплаты
Macik
#13 07.09.2014 22:58
#39817 esclkm:

 Именя файлов - я больше за сильн котонти: README.ru.md

Не возражаю.

про гитхаб пэйдзэс я если честно не совсем знаю, что это такое.

Ты сам привел ссылку. В кратце, это отдельный бранч в репозитории который позволяет залитые в него html просматривать как обычный сайт на страницах гитхаба. Пример GHP для репозитория cot-lazyload  http://macik.github.io/cot-lazyload/demo.html 

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

Давай тогда плясать от структуры. Пиши список что по твоему там должно быть по пунктам (ссылка на автора, мейл автора, ссылка на доки, требуемая версия, …). Если список не будет глобальным можно подумать над расширением setup.php и не городить отдельный файл. 
Если решаем отдельный файл я бы (опять же) придерживался бы стандартов (composer.json). Есть такая штука как Composer. Это менеджер пакетов для PHP. У него есть файл описания пакетов, который достаточно подробный и нам может подойти с минимальными дополнениями (см. описание схемы). 
Кроме того? на перспективу — для компоpера есть класс-надстройка которая позволяет написать установщик пакетов под требования конкретной CMS (см. описание). Под большинство современных CMS расширения уже есть.

з.ы. В прошлом году я с Владимиром общался на эту тему, пришли к выводу, что такой установщик, кроме прочего, мог бы быть полезен для простого формирования кастомных сборок CMS и быстрого их развертывания. Т.е. достаточно иметь 1 json файл, жмякнуть композер — и происходит магия. Движок выкачивается из сети и подтягиваются нужные пакеты со своими зависимостями.

и где будут храниться сязанные изображения?

В принципе пофиг. И зависит от автора сборки. Просто в индексном файле ссылк(и) на них. Но лучше в отдельной папке (thumb) внутри плага/скина.

https://github.com/macik
правильный хостинг — https://goo.gl/fjCa1F
esclkm
#14 08.09.2014 08:22

conposer - менеджер зависимостей. Его цель - быстро установить библиотеку... Скорее его применение станет, когда мы решим, что хватить с установщиком плагинов, переходим на композер.

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

littledev.ru - мой маленький зарождающийся блог о котонти.
снижение стоимости программирования и снижение стоимости производства разные вещи. Первое можно скорее сравнить с раздачей работникам дешевых инструментов, чем со снижением зарплаты
Macik
#15 11.09.2014 10:55

По поводу доков на ГХ. Вот какая нескладуха вырисовывается —

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

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

Идеи решения:

  1. придерживаться идеи, что английская версия главная и ее структура будет основной для ее транслирования по отдельным языкам.
  2. Взять за правило всем тем, кто будет следить за репозиторием (и правила эти расписать), что если в одной из национальных док идет изменение (дополнение статьи или структуры), то их надо (хотя бы на уровне изменения структуры и упоминания пропусков) отметить в английской версии. Остальные нац. версии — поддерживаются закрепленными для этого лицами самостоятельно на основе англ. версии.
  3. Для удобства контроля изменений и необходимости правок статей разделов — использовать гитхабовские тикеты (issues).
  4. Думаю будет удобнее завести на Гите «организацию» в рамках нее сделать по отдельному репозиторию для каждого язака (на которые можно по отдельности давать доступ менеджерам). Таким образом не будет каши из разноязычных тикетов в одном репо. 

 

 

Еще на гитхабе есть такая штука как Wiki. Не знаю применимо ли оно к нашим задачам, но ссылку приведу:

https://github.com/blog/699-making-github-more-open-git-backed-wikis

https://github.com/macik
правильный хостинг — https://goo.gl/fjCa1F

12>>>