Василий Наумкин
С нами с 08 декабря 2012; Место в рейтинге пользователей: #143 минуты назад
Беру свои слова назад, поудалял кеш, всё почистил, и всё заработало.
Наконец таки
Помогите подсказать с выводом результатов в HTML, через Sendit 8
Вчера в 02:35
Не работает. Не сохраняет значение поля сортировки.
MODX Revolution 2.8.6
Minishop2 4.1.1
mSearch2 1.14.70
upd
В категории, где создано кастомн...
msSortFields 13
14 декабря 2024, 17:38
Перестал работать доп, методы запроса изменились похоже, у кого то было такое?
Различное количество выводимых изображений в modInstagram2 2
14 декабря 2024, 11:28
Спасибо за теплые слова Антон.
Документацию пока не начинал делать. Надо бы…
Умные люди советую отдельный проект под документацию и демку поднимат...
MiniShop3 - 1.0.0-alpha 17
13 декабря 2024, 20:27
>Во вторых, компьютер не может ничего такого что в него не заложили.
Это не так. Генеративные сети давно могут. Например, они сами обучились по...
Испытание ИИ Cursor 7
13 декабря 2024, 14:24
Возник вопрос, цена то да, меняется через msOnGetProductPrice или msOnGetProductFields, а самое главное то, что никто не задавался вопросом, что сорти...
Событие msOnGetProductPrice установить old_price 2
12 декабря 2024, 15:55
не помогло к сожалению, подскажите пожалуйста, в каком направлении вы бы продолжили искать?
msOneClick. Ошибка, не появляется модальное окно 2
11 декабря 2024, 15:29
Разобрался!
Использую редактор Tinymcerte
В системных настройках нужно отключить Относительные URL!
Теперь обычные внутренние ссылки корректные...
Jevix чудит 8
11 декабря 2024, 13:12
Спасибо, точно, забыл про это поле. Может есть пример сниппета на запись в это поле? Не могу понять как обратиться к нужному файлу, получить его поле ...
[UserFiles] - Файлы пользователя. 188
11 декабря 2024, 11:13
Спасибо добрейшее. А тип поля «Текстовая область», как-то можно сменить на TinyMCE RTE?
[ExtraFields] Поле "не появляется/не включить" в "Настройках форм/шаблон Това... 2
Тем временем, я проблем не вижу:
Полез в исходники, а там < вместо <=, то есть рейтинг должен быть -3 и ниже.
Ну и поставил минус проверить. Заметка с главной пропала — ура, мой код работает! А верхний коммент свой потом отредактировал.
При рейтинге -3 заметка пропадает с главной — голосование для того и придумано.
Указываем его в настройках вот так:
То есть, id с паролем переехали в массив keys, и добавился параметр scope, где указано нужное.
Здесь уже починил.
У меня, например, личный ПК появился только в 1995, причём не как сейчас принято «для учёбы», а конкретно для игр. Ни о какой работе там и речи не было.
Отступы там, выделение — форматирование, в общем. Сейчас и правда тяжело читать.
У тебя договор с директором, он тебе платит зарплату за твою работу. Его проблемы с клиентами тебя волновать не должны — это его работа их решать. А твоя работа делать сайты, и ты их делаешь.
Директор, вообще-то, получает деньги за твою эксплуатацию и продажу твоего труда. А соответственно, берёт на себя все риски и обязательства по твоей зарплате.
Если он с этим не справляется — это плохой директор, и надо решать вопросы с ним, а не с его заказчиками.
P.S. А по существу — да, конечно, нужен один свой сервер под все dev-проекты, где заказчик сможет всё посмотреть и проверить. А потом выгрузка на его хостинг.
Отдельный сервер под каждый проект не нужен, нет.
Ты же спрашиваешь, как организовать работу для большего количества людей, и тут всё резко усложняется. Хоть для 10 страниц, хоть для 10 тысяч, разницы в логике никакой.
Я уже столько раз критиковал всякое модное, а потом начинал им пользоваться через пару лет, что просто промолчу.
Обычно они любят пихать всякие style в теги и прочее подобное.
А вообще, для тестирования кода пользовательские данные не нужны, можно их набивать через Faker.
Мы сейчас еще и до написания тестов договоримся, такими темпами.
Когда он хочет забрать изменения из основного репозитория, он делает git pull upstream. Основной репо — не его, он может оттуда только читать обновления.
Затем он делает git merge этих изменений со своим локальным репо, добавляя в него, таким образом, обновки от других разрабов и master. Это ему пригодится, чтобы начинать работу в новой ветке, базируясь на актуальном коде.
Когда он закончил работу — он делает git push в свой репозиторий. И тогда у него получается полная копия основого репо + его ветка.
И вот эту ветку он просит забрать и посмотреть владельца основного репо, через pull-request. Что есть буквально «просьба скачать».
Подытоживаем:
— есть основной репо ответственных людей с особыми правами
— есть сколько угодно копий у разрабов
— разрабы в любой момент могут забирать все обновки из основного репо себе
— эти обновки они добавляют в свои копии, и на них базируются при новой работе
— дальше они делают свои ветки и отправляют их к себе в репо
— а потом просят позырить эти правки ответственных людей
— те их забирают в свой репо
Подробнее можно прочитать на Хабре — habr.com/ru/post/125999/
То, о чём ты говоришь — это тестовый сервер, куда выкатываются изменения перед продакшеном. Там максимально полная копия рабочего сайта на текущий момент, которая обновляется с рабочего сайта перед тестированием (если так надо вообще).
Делает это всё только ответственный человек, который выкатывает новую версию. Тестировать должны специально обученные люди — тестировщики, ну или сами разрабы, если народу нет.
По итогам этих тестов могут быть еще исправления, опять тесты и вот только потом, когда на 100% всё хорошо — продакшн.
Именно отсюда шутка про «хуяк-хуяк и в продакшн!», может слышал. Это когда все стадии пропускаются, и обновка сразу пуляется на рабочий проект, желательно в пятницу вечером.
Как ты уже догадался, общий тестовый сервер к локальным серверам разработчиков никакого отношения не имеет, они туда ходят как обычные юзеры, изменить ничего не могут.
Только тут нужно уточнить, что перед началом работ он забрал все изменения из общего репозитория проекта, а после этого создал новую ветку для работы в своём локальном репозитории проекта.
В основном ничего не меняется, всё у него локально.
Верно, при условии, что у каждого разработчика свой собственный dev-сервер.
Верно, и по ходу работ он делает коммиты в свою локальную ветку когда ему удобно.
Неверно. Разработчик никуда не стучится, он просто делает pull-request своей ветки в общий репозиторий, и ответственному человеку приходит уведомление об этом на почту.
Учитывая, что в Github есть раздел Issues и Projects, каждый подобный PR можно сразу привязывать к конкретной задаче, которую он решает.
Верно.
Они скачивают ветку этого разраба и тестируют на своём локальном dev-сервере. И если всё окей — то ответственный человек сливает эту ветку с основной.
После чего разраб может свою ветку удалять — она больше не нужна. Обращаю внимание, что у обычного разраба даже прав нет запушить свои изменения напрямую в master без проверки. Такие права есть только у очень ответственных людей.
Не просто работающий код. А после того, как изменилась основная ветка master, ответственный человек заходит на продакшн и делает git pull, который меняет файлы на рабочем проекте. Ну или еще как-то отправляет именно master на сервер.
Это, конечно, можно автоматизировать.
Слава Orcale, VirtualBox совершенно бесплатен. Есть еще Vagrant, Valet и прочие хорошие локальные среды разработки.
С логикой работы, которую я описал выше.
При одном общем dev-сервере никакого толку от Git не будет, это натуральный публичный дом, в котором кто угодно может порушить что угодно и никогда концов не найти.
Ты считаешь Git каким-то хранилищем готового кода, а не инструментом разработки, когда в него присылаются предлагаемые изменения, а кто-то ответственный их проверяет и добавляет в основную ветку кода.
Вот просто представь разработку ядра MODX по твоей схеме, когда десятки людей что-то делают и тестируют на одном dev-сервере. Ну бред же, так не бывает.
У каждого разраба есть своя копия ядра MODX, своя копия репозитория, и когда кто-то хочет что-то изменить — он делает pull-request, который рассматривается командой MODX и либо отвергается, либо вливается в master.
Нет никакой принципиальной разницы при разработке проекта двумя людьми, или сотнями, принцип один — из маленьких ручейков собирается основной поток.
Обычно кто-то один сливает все pull-request в основную ветку. Он же может и выгрузить эту ветку на основной сервер.
Тут вообще без разницы, как именно доставить файлы: через ftp, sftp, git, голубинной почтой — главное, чтобы было выгружено именно то, что вы сделали, и больше это никто в обход Git не трогал руками.
Это противоречит самой идее Git — делать ветки на любое изменение, а потом их сливать в одну основную.
Git это нифига не для деплоя проекта, это для разрешения конфликтов и хранения истории изменения.
Если 2 разработчика, которые делали разные фичи, поменяли один файл — вы как это будете разрешать при их «закомитили изменения и вытолкнули на гитхаб»? Они сами всё будут в master пушить, что ли?
Нет, у каждого свой dev-сайт, свой копия Git репозитория, в которую он забирает изменения из основной, и из которой отправляет в основную свои изменения. А кто-то главный собирает их все и сливает в основную ветку, которая потом уже и выгружается в production.
и можно работать. Но вряд ли получится такое прикрутить к MODX или Битрикс.
Изначально её придумал Линукс Торвальдс для разработки ядра Linux, и система получилась настолько удачной, что теперь является самой популярной Version Control System.
Github, как следует из названия — просто удобное место для хранения репозиториев Git. Есть еще и другие сервисы, в частности Gitlab, который может быть установлен на собственный сервер.
Основное преимущество Git — простейшее создание новых веток и последующее их слияние, с разрешением конфликтов. Это очень удобно, когда несколько разработчиков делают разные задачи — просто создал свою ветку, отправил pull request в репозиторий, а кто-то один потом сливает все ветки в master перед тестированием и релизом. Собственно, именно так сейчас происходит разработка MODX.
Ну а когда всё слито и проверено — кто-то один может выгрузить новую версию в продакшен напрямую со своего компа. Если изменений много, можно писать какие-то скрипты миграций.
На самом деле, вопросов по работе именно с Git быть не должно — там всё просто, если почитать и подумать. А вот как засунуть в него сайт на MODX или Bitrix, вот это может быть проблемой, да.
Лично у меня всё на файлах, пользовательский контент, картинки и прочее я не синхронизирую и не храню в VCS, для этого есть бэкапы. А в Git только рабочий код, что делает репозитории очень небольшими. Лично я в лимиты Github ни разу не упирался.
Так что не хами пользователям сообщества — и тебе не будут хамить в ответ.
Судя по фразе «В очередной раз убеждаюсь, что МД — это состояние души.», Егорка большой поклонник товарища Пучкова, который и ввёл МД в оборот.
Суета с jQuery очень простая — его через одно место нужно спаривать с Vue, React и другими фреймворками. Так что когда плагин его требует, лично мне проще поискать аналог на чистом JS.
Только непонятно, почему моя работа прям обязана быть связана с дополнениями для MODX? У меня и другие направления есть, не менее интересные.
А насчёт говнокодера — ну тебе же хватило ума назвать меня МД. Почему я не могу назвать тебя говнокодером, который фигачит сайты на том, что знает и не учит ничего больше, потому что времени нет.
С таким подходом вообще ничего нового делать не нужно — старое же работает, так что не трогайте!
Повторяю еще раз, для особо непонятливых: вопросы был к автору дополнения, который полностью переписал js своего дополнения. Если уж ты переписываешь полностью — почему не сделать максимально хорошо, к чему полумеры?
Я вот в новых проектах jQuery не использую, соответственно и это дополнение использовать не буду.