Идея разрешить и поощрять пользователей создавать документацию. Сейчас, чтобы почитать по d7 нужно читать курсы, потом еще гуглить сайт, форум/блоги. Из-за этого много информации которую ищешь, просто не читаешь. А это сильно тормозит саморазвитие и увеличение навыков.
Если весь опыт будет в одном месте, уверен это очень сильно всем поможет.
Чтобы пользователи размещали именно в документацию, нужно их стимулировать бонусами. Размещение информации - премодерируемое.
Создать свод правил по которым нужно размещать документацию. В документации создать перелинковку с курсами.
Чем для этой цели не устраивают вас комментарии к доке и страницам курса? Под каждой из страниц есть форма для добавления, даже в новой доке по D7. Пишите, никто же не против.
Бонусы - никогда не были против раздачи баллов по партнёрской программе. Более того, давали и раздавали такие бонусы за реальную помощь. Деньгами - это уже сложнее. Не уверен, что такая идея получит поддержку у руководства.
Свод правил - не нужен, не нужно вам забивать голову стилями, оформлением и так далее. Просто выдайте то, что считаете нужным. Мы сами и отсеем и оформим.
Если нет страниц, куда надо добавить, просто шлите информацию на мой e-mail и она отобразится в курсах, документации.
Перелинковка доки и курсов - есть, может не везде и не туда, это возможно. Но для этого и создано поле для комментариев. Пишите, добавим линки.
Для донесения полезной информации до нас есть все инструменты. Вопрос в самой информации. Помниться, после того как появилось поле для комментариев, мы создали по просьбам пользователей пустые страницы в доке по неописанным методам, чтобы была возможность добавлять комментарии по этим методам. Помниться даже наполнили с десяток страниц. Но и всё, сейчас дело заглохло.
Идею с голосования снимаю, не надо придумывать какие-то дополнительные механизмы.
ar, ob, db по-моему только мусор добавляют а не читабельность.
Массивы следует именовать с префиксом ar, при этом следующее логическое слово в названии начинается с большой буквы. Например, $arResult, $arModifiedUsers.
Объекты следует именовать с префиксом ob, при этом следующее логическое слово в названии начинается с большой буквы. Например, $obElement, $obUser.
Объект класса CDBResult следует начинать с префикса db, при этом следующее логическое слово в названии начинается с большой буквы. Например, $dbResult.
Уже на протяжении нескольких лет партнеры молча страдают из-за этого жесткого требования от Bitrix - не всегда есть возможность применить данную конфигурацию на хостинге клиента.
Разработчики, которые хоть когда-нибудь работали с библиотекой PHPExcel для обработки операций с XLS помнят, какой это тяжелый труд - переводить весь сайт с UTF-8 на WINDOWS-1251 только из-за того, что эта библиотека не работает с mbstring.func_overload. Или воовсе приходилось отказываться от работы с XLS.
Итак, когда разработчики Symfony ввели требование не поддерживать mbstring.func_overload - это полностью сломало совместимость рабочего окружения Bitrix и всех инструментов, которые используют в своей базе те или иные компоненты от Symfony.
Я понимаю. Сделать это изменение сейчас - не представляется возможным, так как уже есть куча клиентов у которых заинтегрированны алгоритмы с использованием mbstring.func_overload.
Но скоро будет выпуск php7, который итак сломает весь код клиентов. Я предлагаю включить это изменение в релиз Bitrix, который будет работать с php7 (если таковой вообще планируется).
В будущем я собираюсь призывать PHP-сообщество к запрету и удалению функционала mbstring.func_overload. Даже сами разработчики PHP пишут:
Не рекомендуется использовать перегрузку функций в контексте поддиректорий, так как добиться стабильной работы в этом случае пока не удалось, и это может привести к неожидаемому поведению приложения.
Доступны дистрибутивы 20.5.393. Для существующих проектов - выпущены или тестируются обновления модулей (за исключением модуля compression - снят с использования, необходимо удалить).
У нас в веб-студии есть определененный стандарт: все обработчики хранятся в модулях в папке lib/eventhandlers/<код модуля, чье событие обрабатывается>.php Внутри - класс с методами, чьи имена совпадают с названиями событий. Т.е. для события onBeforeUserLogin модуля main обработчик будет такой: \Intervolga\Diving\EventHandlers\Main :: onBeforeUserLogin
Ситуацию усложняет только необходимость подключения этих обработчиков в include.php файле модуля.
Ничего не напоминает? Когда-то у нас была куча include'ов обычных классов и появился спситель - автозагрузчик D7. Может, сделаете аналогичную автозагрузку обработчиков событий?
Для подробного изучения ядра D7 и переработки старых наработок на новое ядро было бы очень полезно, если бы в действующем Api были примеры, как тоже самое написать, используя новое ядро
Под каждой из страниц есть форма для добавления, даже в новой доке по D7. Пишите, никто же не против.
Бонусы - никогда не были против раздачи баллов по партнёрской программе. Более того, давали и раздавали такие бонусы за реальную помощь.
Деньгами - это уже сложнее. Не уверен, что такая идея получит поддержку у руководства.
Свод правил - не нужен, не нужно вам забивать голову стилями, оформлением и так далее. Просто выдайте то, что считаете нужным. Мы сами и отсеем и оформим.
Если нет страниц, куда надо добавить, просто шлите информацию на мой e-mail и она отобразится в курсах, документации.
Перелинковка доки и курсов - есть, может не везде и не туда, это возможно. Но для этого и создано поле для комментариев. Пишите, добавим линки.
Для донесения полезной информации до нас есть все инструменты. Вопрос в самой информации. Помниться, после того как появилось поле для комментариев, мы создали по просьбам пользователей пустые страницы в доке по неописанным методам, чтобы была возможность добавлять комментарии по этим методам. Помниться даже наполнили с десяток страниц. Но и всё, сейчас дело заглохло.
Идею с голосования снимаю, не надо придумывать какие-то дополнительные механизмы.