Чисто теоретически вести пропаганду можно, но вопрос для кого. Если там, кроме пропаганды ничего не будет, то и подписчиков не будет. А если будет актуальная информация для города, то нужен как минимум один модератор на группу.
Вы, надеюсь, в курсе, что Standard JS — это просто кликбейтовое название стиля, а не стандартный кодстайл, как можно было бы логически предположить.
При этом самый популярный кодстайл — это AirBnb.
По мне так оба варианта одной сложности, если известно, что исходные данные не будут содержать ломающих верстку символов.
Вот с SimpleXML, на который мне указали выше, все гораздо удобнее.
Конечно, XMLWriter, крут, но его, по-моему стоит использовать для чего-то большего, чем то, для чего указал автор поста:
Обычно потребность возникает при интеграции со сторонним сервисом, т.к. BetaPRO, OnTime или CDEK
Вот как раз довольно часто вижу ситуацию, когда автор вопроса спрашивает одно, а надо ему что-то другое. Ему дают ответ на его вопрос, но он не отмечает его решением, т.к. не удосужился корректно сформулировать свою проблему.
Перенос сайта осуществляется за три операции, копирование файлов, правка config, экспорт и импорт БД. Все.
Это ведь практически везде так можно, не только у вас. Но с композером, можно еще и не только так.
Вопрос в том, что если с вашим сайтом придется работать другому разработчику. Есть ли документация? Как насчет обновлений безопасности, багфиксов?
Советую глянуть мнение Александра Макарова, одного из основных разработчиков фреймворка Yii, по поводу того, стоит ли писать свою реализацию компонентов или использовать чужую:
К сожалению до понедельника не могу, т.к. проблема всплывает только на работе (как писал выше), хотя дома ОС та же, а наборы дополнений синхронизируются.
Linux Mint 18.1, из расширений — Wappalizer, uBlock Origin, Stylish. Видеокарта Intel.
Скриншоты выше с рабочего компьютера. На домашнем стоит все описанное выше, но баг не воспроизводится.
В 1-м случае (открыт google.ru) при сужении окна появляются стрелки для прокрутки списка вкладок, во 2-м случае (откыт yandex.ru) — не появляются и область просмотра начинает выходить за рамки окна.
Я могу предположить 2 варианта, когда разработчики написали каждый свою миграцию, и последовательность этих миграций может вызвать ошибку в логике кода, не вызывая ошибки в базе:
1. Назначение на 1 поле разных дефолтных значений.
2. Расширение значений 1 и того же поля типа enum.
+ 3. Изменение типа поля — тут совпадение почти невероятно.
2-й случай скорее всего вызовет ошибку независимо от последовательности миграций, т.к. 1 разработчику надо дописать 1 значение, другому — другое. В данном случае последовательность миграций только повлияет на то, у какого пользователя код неверно отработает (у того, чья миграция была выполнена раньеш).
По поводу первого случая — тут да — надо следить, но это довольно редкий случай и следить довольно просто — просто смотреть есть ли установка дефолтного значения, если есть то глянуть, к чему может привести.
Если же скрипт будет пропускать миграции, то в случае с 2+ разработчиками придется всегда смотреть, все ли миграции в верной последовательности. В случае с 3+ разработчиками, насколько я представляю, приблизительно в каждом 3-м мерже придется переименовывать миграции для применения верной последовательности.
Тут вы сами себе проблему делаете из-за «IF (NOT) EXISTS» — там, где надо выводить ошибку, втихую пропускаете выполнение скрипта.
Да и опять же, с какой стати такая ситуация возникнет, что в одной ветке таблицу только создают — это ок, в другой только ее удаляют — эта ветка уже будет зависеть от предыдущей.
Да, именно так.
В моих комментах выше подразумевается Laravel, насколько я понимаю аналогично с Yii.
Как ниже ответил Zhuravljov, проблемы из-за разной последовательности случаются редко, да и их будет видно у мерджера локально при запуске миграций.
Проблема в том, что для шага 2 добавляются следующие шаги для мержера:
2.2. Смотрит, были ли файлы миграций в сливаемой ветке
2.3. Если были, то смотрит, какие у них даты и сравнивает с последним числом в базе.
2.4. Если последняя миграция свежее тех, что в ветке, то переименовывает файлы миграций из ветки, делает еще коммит в мастер с переименованием миграций.
Только после этого выполняется шаг 3.
Потенциально на этих шагах может возникнуть проблема, когда недосмотрел даты, что-то упустил, тогда именно на проде миграции не сработают и ой, хотя на тестовом все было ок.
> А как вы апдейты делаете?
1. Тестирование ветки на тестовом.
2. При успешном тестировании мержер мержит ветку задачи в мастер локально.
3. Выполняются миграции локально у мержера, если идут какие-то ошибки в локальных миграциях, то решается вопрос с разрабами или силами мержера.
4. Если локально у мержера все ок в мастере, то результаты мержа выкладываются в репу, выливаются на прод, запускаются миграции (скрипт миграций всегда запускается автоматом при пуле мастера на проде, дальше скрипт сам решает есть что выполнять или нет).
А — накатываются все миграции, которых не было
Б — накатываются миграции, которые свежее последней
1. Человек не думает:
А — обычно ничего не произойдет, максимум, миграция не сработает, т.к. будут конфликт из-за другой миграции (поле уже есть, такая таблица уже создана и т.п.)
Б — код не работает, т.к. нет необходимых таблиц, полей и т.п.
2. Человек подумал:
А — запустил миграции, все ок
Б — переименовал миграции в особом порядке, запустил, все ок.
Итог — в случае Б вероятность все сломать, когда не думаешь выше, когда думаешь, надо выполнять лишние действия.
Все-таки лучше не сразу отправлять на главную, а показать 404 и, если уж так надо, то добавить мета-тег c [http-equiv="refresh"], чтобы пользователя перекидывало на главную через несколько секунд (работает без JS):
Чисто теоретически вести пропаганду можно, но вопрос для кого. Если там, кроме пропаганды ничего не будет, то и подписчиков не будет. А если будет актуальная информация для города, то нужен как минимум один модератор на группу.
Хм, ещё один интересный пунктик — а вы на каких основаниях их уволили?
Можно так
Вы, надеюсь, в курсе, что Standard JS — это просто кликбейтовое название стиля, а не стандартный кодстайл, как можно было бы логически предположить.
При этом самый популярный кодстайл — это AirBnb.
По мне так оба варианта одной сложности, если известно, что исходные данные не будут содержать ломающих верстку символов.
Вот с SimpleXML, на который мне указали выше, все гораздо удобнее.
Конечно, XMLWriter, крут, но его, по-моему стоит использовать для чего-то большего, чем то, для чего указал автор поста:
В стандартной библиотеке все слишком избыточно. Ваша же 2-я ссылка с примером.
Точно, давно им пользовался, подзабыл ) Сейчас же в основном апи на JSON'ах делают.
По-моему гораздо удобней было бы это делать через классы
Вот как раз довольно часто вижу ситуацию, когда автор вопроса спрашивает одно, а надо ему что-то другое. Ему дают ответ на его вопрос, но он не отмечает его решением, т.к. не удосужился корректно сформулировать свою проблему.
Это ведь практически везде так можно, не только у вас. Но с композером, можно еще и не только так.
Вопрос в том, что если с вашим сайтом придется работать другому разработчику. Есть ли документация? Как насчет обновлений безопасности, багфиксов?
Советую глянуть мнение Александра Макарова, одного из основных разработчиков фреймворка Yii, по поводу того, стоит ли писать свою реализацию компонентов или использовать чужую:
https://youtu.be/EfL8lsUTlFo?t=9209 — ошибки Yii 2.0
https://youtu.be/EfL8lsUTlFo?t=10271 — конкретно, в чем разумнее подход Laravel по сравнению с подходом Yii.
К сожалению до понедельника не могу, т.к. проблема всплывает только на работе (как писал выше), хотя дома ОС та же, а наборы дополнений синхронизируются.
Linux Mint 18.1, из расширений — Wappalizer, uBlock Origin, Stylish. Видеокарта Intel.
Скриншоты выше с рабочего компьютера. На домашнем стоит все описанное выше, но баг не воспроизводится.
В 1-м случае (открыт google.ru) при сужении окна появляются стрелки для прокрутки списка вкладок, во 2-м случае (откыт yandex.ru) — не появляются и область просмотра начинает выходить за рамки окна.
1. Назначение на 1 поле разных дефолтных значений.
2. Расширение значений 1 и того же поля типа enum.
+ 3. Изменение типа поля — тут совпадение почти невероятно.
2-й случай скорее всего вызовет ошибку независимо от последовательности миграций, т.к. 1 разработчику надо дописать 1 значение, другому — другое. В данном случае последовательность миграций только повлияет на то, у какого пользователя код неверно отработает (у того, чья миграция была выполнена раньеш).
По поводу первого случая — тут да — надо следить, но это довольно редкий случай и следить довольно просто — просто смотреть есть ли установка дефолтного значения, если есть то глянуть, к чему может привести.
Если же скрипт будет пропускать миграции, то в случае с 2+ разработчиками придется всегда смотреть, все ли миграции в верной последовательности. В случае с 3+ разработчиками, насколько я представляю, приблизительно в каждом 3-м мерже придется переименовывать миграции для применения верной последовательности.
Да и опять же, с какой стати такая ситуация возникнет, что в одной ветке таблицу только создают — это ок, в другой только ее удаляют — эта ветка уже будет зависеть от предыдущей.
В моих комментах выше подразумевается Laravel, насколько я понимаю аналогично с Yii.
Как ниже ответил Zhuravljov, проблемы из-за разной последовательности случаются редко, да и их будет видно у мерджера локально при запуске миграций.
2.2. Смотрит, были ли файлы миграций в сливаемой ветке
2.3. Если были, то смотрит, какие у них даты и сравнивает с последним числом в базе.
2.4. Если последняя миграция свежее тех, что в ветке, то переименовывает файлы миграций из ветки, делает еще коммит в мастер с переименованием миграций.
Только после этого выполняется шаг 3.
Потенциально на этих шагах может возникнуть проблема, когда недосмотрел даты, что-то упустил, тогда именно на проде миграции не сработают и ой, хотя на тестовом все было ок.
1. Тестирование ветки на тестовом.
2. При успешном тестировании мержер мержит ветку задачи в мастер локально.
3. Выполняются миграции локально у мержера, если идут какие-то ошибки в локальных миграциях, то решается вопрос с разрабами или силами мержера.
4. Если локально у мержера все ок в мастере, то результаты мержа выкладываются в репу, выливаются на прод, запускаются миграции (скрипт миграций всегда запускается автоматом при пуле мастера на проде, дальше скрипт сам решает есть что выполнять или нет).
А — накатываются все миграции, которых не было
Б — накатываются миграции, которые свежее последней
1. Человек не думает:
А — обычно ничего не произойдет, максимум, миграция не сработает, т.к. будут конфликт из-за другой миграции (поле уже есть, такая таблица уже создана и т.п.)
Б — код не работает, т.к. нет необходимых таблиц, полей и т.п.
2. Человек подумал:
А — запустил миграции, все ок
Б — переименовал миграции в особом порядке, запустил, все ок.
Итог — в случае Б вероятность все сломать, когда не думаешь выше, когда думаешь, надо выполнять лишние действия.
Все-таки лучше не сразу отправлять на главную, а показать 404 и, если уж так надо, то добавить мета-тег c [http-equiv="refresh"], чтобы пользователя перекидывало на главную через несколько секунд (работает без JS):