Василий Наумкин

Потом окажется, что все 3 сайта на одном сервере и у него проблемы с коннектом до сервера modstore

Тем временем, я проблем не вижу:

Я, как раз, последний минус поставил (оценки в хронологическом порядке показываются, это легко заметить), потому что у заметки был рейтинг -2, а на главной она всё еще висела.

Полез в исходники, а там < вместо <=, то есть рейтинг должен быть -3 и ниже.

Ну и поставил минус проверить. Заметка с главной пропала — ура, мой код работает! А верхний коммент свой потом отредактировал.

Просто поставь минус.

При рейтинге -3 заметка пропадает с главной — голосование для того и придумано.

Мне кажется, это у Яндекса что-то сломалось и scope стал обязательным.

Указываем его в настройках вот так:

{"keys":{"id":"айди","secret":"пароль"},"scope":"login:birthday login:email login:info"}

То есть, id с паролем переехали в массив keys, и добавился параметр scope, где указано нужное.

Здесь уже починил.

Это если ты деньги кодом зарабатываешь с 1994 года, то нас всех ждут великие открытия, не сомневаюсь!

У меня, например, личный ПК появился только в 1995, причём не как сейчас принято «для учёбы», а конкретно для игр. Ни о какой работе там и речи не было.

Я думаю, тут больше вопрос к оформлению заметки.

Отступы там, выделение — форматирование, в общем. Сейчас и правда тяжело читать.

Тогда ты в корне неправильно смотришь на проблему.

У тебя договор с директором, он тебе платит зарплату за твою работу. Его проблемы с клиентами тебя волновать не должны — это его работа их решать. А твоя работа делать сайты, и ты их делаешь.

Директор, вообще-то, получает деньги за твою эксплуатацию и продажу твоего труда. А соответственно, берёт на себя все риски и обязательства по твоей зарплате.

Если он с этим не справляется — это плохой директор, и надо решать вопросы с ним, а не с его заказчиками.

P.S. А по существу — да, конечно, нужен один свой сервер под все dev-проекты, где заказчик сможет всё посмотреть и проверить. А потом выгрузка на его хостинг.

Отдельный сервер под каждый проект не нужен, нет.

Или этот код позволяет использовать параметры сниппета в качестве модификатора?

Именно

И честно говоря считаю, что для одного человека больше вообще ничего не нужно.

Для одного — да.

Ты же спрашиваешь, как организовать работу для большего количества людей, и тут всё резко усложняется. Хоть для 10 страниц, хоть для 10 тысяч, разницы в логике никакой.

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

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

Наверное, стоит предупредить, что Jevix многое может повырезать при выводе текста, сгенерированного таким редактором.

Обычно они любят пихать всякие style в теги и прочее подобное.

В MODX это неплохо разруливает Gitify, насколько я знаю.

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

Мы сейчас еще и до написания тестов договоримся, такими темпами.

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

Когда он хочет забрать изменения из основного репозитория, он делает git pull upstream. Основной репо — не его, он может оттуда только читать обновления.

Затем он делает git merge этих изменений со своим локальным репо, добавляя в него, таким образом, обновки от других разрабов и master. Это ему пригодится, чтобы начинать работу в новой ветке, базируясь на актуальном коде.

Когда он закончил работу — он делает git push в свой репозиторий. И тогда у него получается полная копия основого репо + его ветка.

И вот эту ветку он просит забрать и посмотреть владельца основного репо, через pull-request. Что есть буквально «просьба скачать».

Подытоживаем:
— есть основной репо ответственных людей с особыми правами
— есть сколько угодно копий у разрабов
— разрабы в любой момент могут забирать все обновки из основного репо себе
— эти обновки они добавляют в свои копии, и на них базируются при новой работе
— дальше они делают свои ветки и отправляют их к себе в репо
— а потом просят позырить эти правки ответственных людей
— те их забирают в свой репо

Подробнее можно прочитать на Хабре — habr.com/ru/post/125999/

Тебе всё правильно говорят, просто ты не понимаешь, что dev-сервер у каждого разработчика свой.

То, о чём ты говоришь — это тестовый сервер, куда выкатываются изменения перед продакшеном. Там максимально полная копия рабочего сайта на текущий момент, которая обновляется с рабочего сайта перед тестированием (если так надо вообще).

Делает это всё только ответственный человек, который выкатывает новую версию. Тестировать должны специально обученные люди — тестировщики, ну или сами разрабы, если народу нет.
По итогам этих тестов могут быть еще исправления, опять тесты и вот только потом, когда на 100% всё хорошо — продакшн.

Именно отсюда шутка про «хуяк-хуяк и в продакшн!», может слышал. Это когда все стадии пропускаются, и обновка сразу пуляется на рабочий проект, желательно в пятницу вечером.

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

Просто в моей голове все примерно так выстроено — разработчик работает с кодом, через ide.

Верно.

Только тут нужно уточнить, что перед началом работ он забрал все изменения из общего репозитория проекта, а после этого создал новую ветку для работы в своём локальном репозитории проекта.

В основном ничего не меняется, всё у него локально.

Сохраненные, измененные или созданные им файлы попадают на сервер dev

Верно, при условии, что у каждого разработчика свой собственный dev-сервер.

Разработчик работает до тех пор, пока не решил задачу.

Верно, и по ходу работ он делает коммиты в свою локальную ветку когда ему удобно.

Стучится кому-то кто ответственный и говорит — сделано, проверяйте.

Неверно. Разработчик никуда не стучится, он просто делает pull-request своей ветки в общий репозиторий, и ответственному человеку приходит уведомление об этом на почту.

Учитывая, что в Github есть раздел Issues и Projects, каждый подобный PR можно сразу привязывать к конкретной задаче, которую он решает.

Ответственные люди проверяют функционирование и говорят — супер.

Верно.

Они скачивают ветку этого разраба и тестируют на своём локальном dev-сервере. И если всё окей — то ответственный человек сливает эту ветку с основной.

После чего разраб может свою ветку удалять — она больше не нужна. Обращаю внимание, что у обычного разраба даже прав нет запушить свои изменения напрямую в master без проверки. Такие права есть только у очень ответственных людей.

После того как работающий когд оказался на гитхабе он голубиной почтой передается на продакшен.

Не просто работающий код. А после того, как изменилась основная ветка master, ответственный человек заходит на продакшн и делает git pull, который меняет файлы на рабочем проекте. Ну или еще как-то отправляет именно master на сервер.

Это, конечно, можно автоматизировать.

выделенный сервер на 100 гигов чтобы развернуть один dev сайт будет обходится в десятки тысяч в месяц, а держать три таких сервера по одному для каждого разработчика — это невозможно

Слава Orcale, VirtualBox совершенно бесплатен. Есть еще Vagrant, Valet и прочие хорошие локальные среды разработки.

С чем именно связано то, что вы говорите, что нужно для каждого разработчика свой dev -сайт?

С логикой работы, которую я описал выше.

При одном общем dev-сервере никакого толку от Git не будет, это натуральный публичный дом, в котором кто угодно может порушить что угодно и никогда концов не найти.

Ты считаешь Git каким-то хранилищем готового кода, а не инструментом разработки, когда в него присылаются предлагаемые изменения, а кто-то ответственный их проверяет и добавляет в основную ветку кода.

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

У каждого разраба есть своя копия ядра MODX, своя копия репозитория, и когда кто-то хочет что-то изменить — он делает pull-request, который рассматривается командой MODX и либо отвергается, либо вливается в master.

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

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

То есть, когда берёшь новые проект на поддержку, нужно разобраться, что он из себя представляет? Во дела!

Что скачивать zip архив и по ftp заменять файлы?

Обычно кто-то один сливает все pull-request в основную ветку. Он же может и выгрузить эту ветку на основной сервер.
Тут вообще без разницы, как именно доставить файлы: через ftp, sftp, git, голубинной почтой — главное, чтобы было выгружено именно то, что вы сделали, и больше это никто в обход Git не трогал руками.

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

Это противоречит самой идее Git — делать ветки на любое изменение, а потом их сливать в одну основную.
Git это нифига не для деплоя проекта, это для разрешения конфликтов и хранения истории изменения.

Если 2 разработчика, которые делали разные фичи, поменяли один файл — вы как это будете разрешать при их «закомитили изменения и вытолкнули на гитхаб»? Они сами всё будут в master пушить, что ли?

Нет, у каждого свой dev-сайт, свой копия Git репозитория, в которую он забирает изменения из основной, и из которой отправляет в основную свои изменения. А кто-то главный собирает их все и сливает в основную ветку, которая потом уже и выгружается в production.

В случае к примеру если разработчики убили сайт на dev нужно быстро развернуть им свежую версию, максимально приближенную к pro.

git clone
composer install
phinx migrate
phinx seed:run

и можно работать. Но вряд ли получится такое прикрутить к MODX или Битрикс.

Система контроля версий, по идее, служит как раз для совместной разработки, а не выгрузки на сайт — так что Git на продакшене вовсе не обязателен.
Изначально её придумал Линукс Торвальдс для разработки ядра Linux, и система получилась настолько удачной, что теперь является самой популярной Version Control System.

Github, как следует из названия — просто удобное место для хранения репозиториев Git. Есть еще и другие сервисы, в частности Gitlab, который может быть установлен на собственный сервер.

Основное преимущество Git — простейшее создание новых веток и последующее их слияние, с разрешением конфликтов. Это очень удобно, когда несколько разработчиков делают разные задачи — просто создал свою ветку, отправил pull request в репозиторий, а кто-то один потом сливает все ветки в master перед тестированием и релизом. Собственно, именно так сейчас происходит разработка MODX.

Ну а когда всё слито и проверено — кто-то один может выгрузить новую версию в продакшен напрямую со своего компа. Если изменений много, можно писать какие-то скрипты миграций.
На самом деле, вопросов по работе именно с Git быть не должно — там всё просто, если почитать и подумать. А вот как засунуть в него сайт на MODX или Bitrix, вот это может быть проблемой, да.

Лично у меня всё на файлах, пользовательский контент, картинки и прочее я не синхронизирую и не храню в VCS, для этого есть бэкапы. А в Git только рабочий код, что делает репозитории очень небольшими. Лично я в лимиты Github ни разу не упирался.

Мучают меня смутные подозрения, что можно было бы эту задачу решить по другому. Но сейчас ничего такого не приходит в голову :-(.

[[!pdoMenu?
    &checkPermissions=`list`
]]

Егорка ты потому, что фамилии у тебя нет, возраст непонятен, обзываешь пользователей МД и вообще, сообщение твоё весьма вызывающе написано. Д'Артаньян, в общем.

Так что не хами пользователям сообщества — и тебе не будут хамить в ответ.

А что такое МД?

Полагаю, «Малолетний Дебил» ©.

Судя по фразе «В очередной раз убеждаюсь, что МД — это состояние души.», Егорка большой поклонник товарища Пучкова, который и ввёл МД в оборот.

Суета с jQuery очень простая — его через одно место нужно спаривать с Vue, React и другими фреймворками. Так что когда плагин его требует, лично мне проще поискать аналог на чистом JS.

Про свои планы я уже писал — modx.pro/news/19512

Только непонятно, почему моя работа прям обязана быть связана с дополнениями для MODX? У меня и другие направления есть, не менее интересные.

А насчёт говнокодера — ну тебе же хватило ума назвать меня МД. Почему я не могу назвать тебя говнокодером, который фигачит сайты на том, что знает и не учит ничего больше, потому что времени нет.

С таким подходом вообще ничего нового делать не нужно — старое же работает, так что не трогайте!

Повторяю еще раз, для особо непонятливых: вопросы был к автору дополнения, который полностью переписал js своего дополнения. Если уж ты переписываешь полностью — почему не сделать максимально хорошо, к чему полумеры?

Я вот в новых проектах jQuery не использую, соответственно и это дополнение использовать не буду.