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

Просто в моей голове все примерно так выстроено — разработчик работает с кодом, через 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 не использую, соответственно и это дополнение использовать не буду.

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

Если что, мне 37 лет — и я учу новое. И если уж у меня на это времени хватает, я хз какие у тебя отмазки могут быть, дорогой мой говнокодер.

Так что, автор не может просто любить jquery? Человек не обязан знать все языки в мире и разбираться во всех технологиях, это нормально.

Я так и понял, что для тебя jQuery и Javascript — это разные языки и технологии.

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

Вопрос, кажется, вообще не тебе задавали. Непонятно, откуда такой энтузиазм в защите jQuery. Не хочется Javascript учить? Ну бывает.

Поэтому jquery это фреймворк языка javascript, laravel — это фрейворк языка php. Так что сравнивать их вполне законно.

jQuery — библиотека, а не фреймворк. Для сведения — proglib.io/p/framework-or-library/

Мне кажется вы так говорите только потому

Что мои дополнения требуют jQuery для работы и я регулярно отвечаю на вопросы по его подключению в поддержке.

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

Речь тут о том, что раз переписывается JS дополнения, зачем тащить ненужную зависимость? Никто не предлагает переписывать сразу всё и всем, но раз уж делаешь заново — нафига нужен jQuery?

Ответа от автора по-прежнему нет.

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

Или еще лучше — на сайте будет jQuery, но не той версии, которая нужна. Или с подключенными конфликтующими плагинами.

Когда я соберусь переписывать JS в моих допах, там точно не будет jQuery.

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

Ну ты же любишь использовать плейсхолдеры в запросах, вот тебе еще один: {'table_prefix' | option}

А если серьёзно, то ты пишешь очень сложный запрос, который не понадобится 99% пользователей pdoTools, а может и вообще MODX.
Он не станет менее сложным, если засунуть его в массив Fenom, никто ничего от этого не выиграет.

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

Периодически будут находиться люди, пытающиеся наворотить какую-нибудь фигню с этими параметрами. Как сейчас это делают с долбаным tvFilters.

Рейтинг этой заметки на данный момент составляет 0 при 34 комментариях, что уже намекает на её полезность.

Я этот PR гарантированно не приму, удачи в развитии своих дополнений.

И мне он нравиться :-).

Ну не может быть хороший программист неграмотным. tsya.ru

Проявите ответственность :-)

Я и так много времени на тебя потратил. Иди, просвещайся.

Нужен был запрос типа такого:

Александр не знает, что xPDO и следовательно, pdoTools, прекрасно понимают сырые запросы, если засунуть их в строку внутри массива.

И тогда вполне возможно написать даже то, что он приводит в начале заметки:

{'!pdoResources' | snippet :[
    'class' => 'tSkladDetNSLink',
    'select' => ['*
        FROM `modx_tsklad_detail_naryad_smena_link` AS `tSkladDetNSLink`
        LEFT JOIN `modx_tsklad_order_list` `Detail` ON Detail.id=tSkladDetNSLink.det_id
        LEFT JOIN `modx_tsklad_orders` `Order` ON Order.id=Detail.sk_order_id
        LEFT JOIN `modx_tsklad_naryad` `Naryad` ON Naryad.id=tSkladDetNSLink.naryad_id
        LEFT JOIN `modx_tsklad_smena` `Smena` ON Smena.id=tSkladDetNSLink.smena_id
        LEFT JOIN `modx_nomenclature_detail_nom` `DetailNom` ON DetailNom.id=Detail.nom_id
        LEFT JOIN `modx_nomenclature_detail_class` `DetailClass` ON DetailClass.id=DetailNom.class_id
        LEFT JOIN `modx_nomenclature_type_job` `NomTypeJob` ON NomTypeJob.id=DetailClass.type_job_id
        LEFT JOIN (
            SELECT NextDNL.det_id AS next_det_id, NextDNL.naryad_id AS next_naryad_id, NextN.name AS next_naryad_name, NextDNL.smena_id AS next_smena_id, NextS.date AS next_smena_date, NextS.number AS next_smena_number
            FROM `modx_tsklad_detail_naryad_smena_link` AS `NextDNL`
            LEFT JOIN `modx_tsklad_smena` `NextS` ON NextS.id=NextDNL.smena_id
            LEFT JOIN `modx_tsklad_naryad` `NextN` ON NextN.id=NextDNL.naryad_id
            ORDER BY NextS.date ASC, NextS.number ASC) `NextDNL1` 
                ON tSkladDetNSLink.det_id = NextDNL1.next_det_id AND 
                (NextDNL1.next_smena_date > Smena.date OR (NextDNL1.next_smena_date = Smena.date AND NextDNL1.next_smena_number > Smena.number)
        ) 
        AND NextDNL1.next_smena_id = (
            SELECT NextDNL.smena_id AS on_next_smena_id
            FROM `modx_tsklad_detail_naryad_smena_link` AS `NextDNL`
            LEFT JOIN `modx_tsklad_smena` `NextS` ON NextS.id=NextDNL.smena_id
            LEFT JOIN `modx_tsklad_naryad` `NextN` ON NextN.id=NextDNL.naryad_id
            WHERE NextS.date > Smena.date OR (NextS.date = Smena.date AND NextS.number > Smena.number)
            ORDER BY NextS.date ASC, NextS.number ASC
            LIMIT 1
        )
        LEFT JOIN `modx_plazma_list` `PlazmaList` ON PlazmaList.det_id=tSkladDetNSLink.det_id
    '],
    'where' => [
        "(`Detail`.`sech` = 'pryam' AND `Detail`.`name` = 'зонт' AND `DetailNom`.`A` = '2000' AND `DetailNom`.`B` = '1500' AND `DetailNom`.`a_s` = '500' AND `DetailNom`.`b_s` = '500' AND `Detail`.`metall` = '0,7Ц' AND `Detail`.`L` = '0' AND `Detail`.`comment` = 'тип 1, ф355 заузить под наш отвод' AND `tSkladDetNSLink`.`smena_id` = 65 AND `tSkladDetNSLink`.`naryad_id` = 8 AND `NextDNL1`.`next_smena_id` = '66' AND `PlazmaList`.`file_true` = '0')"
    ],
    'sortby' => 'Detail.sech DESC, Detail.name ASC, DetailNom.A DESC, DetailNom.B DESC, DetailNom.a_s DESC, DetailNom.b_s DESC, Detail.metall DESC, Detail.L DESC, Detail.comment',
    'sortdir' => 'DESC'
    'limit' => 0,
    'showLog' => 1,
]}

Запрос, вполне себе, подготавливается

У меня он не может быть выполнен просто потому, что таких таблиц в системе нет.

Но можно сравнить исходные параметры и конечный код — они идентичны, за исключением FROM из несуществующей таблицы (что при наличии модели tSkladDetNSLink будет заменено на FROM `modx_tsklad_detail_naryad_smena_link` AS `tSkladDetNSLink`) и экранирования сортировки (которой xPDO закрывает старую уязвимость).


Так что, кому уж прям очень нужны подзапросы в pdoTools — они уже там есть, с самого начала.

принимать этот PR Не требуется..

А нафига ж ты его прислал с своём PR?

Еще через минут 20 будет.

Не надо.

Что-то я совсем не понял с честь чего у вас такой вопрос?? «построение запроса через xPDO приводит к ошибке работы Fenom» — вроде нигде такого не говорил.

У тебя с памятью беда, или с логикой?



Вот это вот — оно про что?

Почему у тебя какие-то ошибки в парсинге именно после выполнения запроса? Какие ты там display и font меняешь, зачем? Какое оно имеет отношение к запросам или подзапросам в БД?

Или ты (я только сейчас об этом подумал) проверяешь свой новый придуманный синтаксис на pdoFetch с твоими изменениями, и без них? И приводишь как доказательство, что твой синтаксис без твоих изменений в pdoFetch не работает?

Если это и правда так, то я вообще уже не знаю, куда в скорую звонить, в какой регион.

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

А еще авторы бывают опытными, и понимающими, что нужно их дополнениям, а что нет.

Пиши свои допы, развивай — Сергей верно говорит.

Подзапросы вроде вещь актуальная. Разве нет?

Внезапно, нет.

pdoTools появился в 2013 году и целых 7 лет эти подзапросы никого не волновали. И сейчас не волнуют, увы.

Саша, ты несёшь такую пургу, что я просто теряюсь.

Скажи пожалуйста, каким образом у тебя построение запроса через xPDO приводит к ошибке работы Fenom? Это откуда должны расти руки, чтобы так получалось? Ты понимаешь, что Fenom в pdoTools был добавлен лишь в версии 2.0, и как-то до этого запросы прекрасно строились без него?

Пока ты не ответишь на этот вопрос, я не вижу смысла продолжать общение.

А авторы Tikkets вообще собираются редактор сообщений обновлять?

Нет, не собираются.

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

И будешь его потом поддерживать бесплатно, годами.