Столкнулся с такой ерундой, когда настраивал автоматический деплой на сервер. Так как проект небольшой и всего один, то проблема была решена перезагрузкой апача.
Почему-то очень сложно читать код. Какой-то инородный для меня язык // не критика, просто личные ощущения
Но за статью спасибо. Не так давно понял всю прелесть автоматических тестов. Когда выкатывание в продакшн почти перестало быть ритуалом. Полное покрытие кода всеми сценариями сделать очень сложно, но когда все основное проверено и хорошо работает, как-то крепче спится
Pipelines условно платная услуга. 50 минут в месяц может не хватить. Из этих соображений некоторые пилят свои велосипеды (как я и автор статьи).
Гитлаб хоть и бесплатный, но для него лучше купить второй сервер, чтобы сильно основной не нагружать. А, откровенно говоря, не все могут позволить себе иметь два сервера (как я и, возможно, автор статьи)
Но Вы абсолютно правы. Специализированные, изначально интегрированные и проверенные временем и тысячами разработчиками инструменты намного лучше и надежнее, чем подобные решения.
Там есть кастомные настройки, которые можно запустить вручную. Там в этом плане все достаточно гибко.
Насколько я знаю, запускается он только на последний коммит и только так, как настроишь. У нас, например, ветка master для разработки, которая ни на что не влияет. Там особо не нужно ничего запускать. А вот ветка release уже предназначена для кода в продакшн. Вот там вот уже и запускать тесты, сборку и прочее.
Я хочу сначала попробовать сделать так, чтобы все запускалось через pipeline, но работало как раньше, через веб-хуки. Если времени хватит, то перейдем в pipeline полностью. Или если начальство не по-жадничает $10 в месяц на дополнительные минуты)
Раньше тоже пользовался HipChat. Но столкнулся с проблемой, что на мобилках приложение не особо держится и вычищается. Из-за чего все уведомления пролетали мимо. Мы себе этого позволить не могли, так как в таких сообщениях могла содержаться очень важная на текущий момент информация. Что я только не делал (вроде там галочка была, чтобы он не терял соединение при сворачивании, но проблемы она не решала; это было давно, возможно, сейчас проблема исправлена). В итоге перешли в Slack. С тех пор таких проблем не наблюдалось.
Говоря про Bitbucket веб-хуки. Это хорошо, чтобы только уведомить сервер о том, что произошел пуш. И не более. У меня тоже происходила сборка по хуку, но продолжительность сборки была дольше, чем Bitbucket позволял мне, поэтому происходил timeout и еще две попытки, что запукало 3 сборки почти параллельно. Сейчас сделано так: веб-хук только записывает в файл, что произошло изменение (в моем случае пишет еще и в какую ветку, чтобы можно было собрать dev и release отдельно; у меня информация хранится в JSON массиве, чтобы если я запушил сразу в две ветки, прошло две независимых сборки). А по крону запускается ежеминутно скрипт, который и запускает сборку.
Сейчас в планах запуск тестов и сборку проекта перенести в Pipelines Это почти как CI, но попроще и интегрировано прямо в bitbucket. Там 50 минут в месяц бесплатно; для малых проектов хватит. Если хочется больше, то можно докупить 1000 минут за $10.
Безопасность, это другой вопрос (важный, но другой). Тут главное подход. И он, как мне кажется, более гибкий и универсальный, чем тот, который описан в статье.
Комментариев слишком много, может быть кто-то уже высказывал подобную мысль. Как вы думаете, такая схема не лучше:
Я захожу на сайт, в форму входа вбиваю свой email, отображается сообщение ожидания.
На этот самый email приходит сообщение с ссылкой, подтверждающей вход.
Когда я перешел по ссылке, на самом сайте обновляется страница (или редирект), что свидетельствует о том, что авторизация прошла успешно.
Над вопросом безопасности, конечно, стоит подумать. Но польза от этого подхода в том, что не обязательно подтверждать вход с того же устройства. Залогиниться можно, допустим, на компе, а подтвердить на телефоне. Потом, клиентом может быть не только браузер, но и мобильное приложение или даже телевизор.
При запросе авторизации можно отправить либо тип клиента (web, mobile, tv), либо callback url, чтобы, если клиент — web или есть url, то показать кнопку, через которую можно вернуться на сайт.
Либо я неправильно настроил babel, но построчное выполнение кода внутри генератора вообще уводит куда-то в сторону (redux-saga). Если какая-то ошибка, никакие source-map'ы не помогают. Стектрейс вообще неадекватный в консоли.
Не так давно решил освоить FB. Все ты ничего, но "У вас новая рекомендация друга" по 15 штук не день в уведомлениях прям вымораживает. И не знаю как отключить. Гугл упорно молчит.
У меня немного другая идея. Декоратор bem работает не через аргументы рендера, а через пропсы:
this.props.bemHelper()
А декоратор DI (или renderInjector) как раз запихивает аргументы в рендер:
@renderInject(A, B, C)
class Button extends Component {
render(A, B, C) {...}
}
Таким образом никто никому не мешает. И порядок в данном случае вообще не будет иметь значения.
Кстати говоря, мне нравится реализация react-bem-helper. Можете посмотреть. Хочу себе сделать такую же как у вас обертку в виде декоратора но с возможностями этого хелпера
DI через декоратор — тоже классная идея (очень классная). Но мне кажется, что это уже другая задача. Декоратор для bem должен существовать только для того, чтобы генерировать классы для блоков и элементов. А для DI можно отдельный декоратор написать, который будет заниматься проталкиванием зависимостей в рендер. И никто не запрещает использовать их вместе:
Простите, цифры должны были идти по порядку, отредактировать уже не даёт. Поправьте, если кто может.
У React очень гибкое API. Можно легко перехватывать и переопределять свойства, как это делает, например, react-redux в декораторе connect. Поэтому и интересно, почему не пропсы?
Вы используете чистый css с пост-процессорами или пре-процессор у вас тоже какой-то используется (sass, less...)? Как вы проталкиваете переменные в стили, например, фирменный цвет?
У тебя ошибка в слове «людми»!
Ой, простите…
Мне кажется, что в слове «людьми» должен стоять мягкий знак. Нарушаются правила русского языка.
(применение на практике)
Активно в проекте использую redux. Полюбился он мне. Многие ругают его за многословность и шаблонность. Поставил redux-actions и радуюсь жизни. Асинхронная логика лежит в саге, в редких случаях в middleware. Данные храню нормализовано, для выборок использую селекторы. Зато все прозрачно. Проблемы с дебагом возникают только в генераторах.
Я тоже пишу код, как хочу, а потом нажимаю Ctrl+Alt+L (В поиске: Reformat Code) и привожу его к общему стандарту. Помимо этого, PHPStorm неплохо синхронизируется с настройками .eslintrc.json.
Тоже столкнулся с такой проблемой. Мне особенно нравится в 16-й версии, что в качестве рендера можно вернуть массив. Но не тут-то было. Одна из часто используемых библиотек, а именно react-bootstrap, не работает (не работала; сейчас не знаю) с новой версией React'a (проблема всплывает при использовании модальных окон)… Поэтому приходится пока что сидеть на последней 15-й версии.
Использую автоформатирование, которое даёт мне JetBrains. Неплохо справляется со своей задачей. И ESLint сбоку ещё повесил, чтобы в случае косяков со стороны IDE форматтера, я мог это сразу увидеть. Поэтому для себя не вижу смысла использовать ещё и Prettier.
class C {
public function __get($name)
{
if ($name === 'i') {
return 0;
}
}
public function __set($name, $value)
{
if ($name === 'i') {
file_put_contents('/file', $value);
}
}
}
Я не говорю, что так делать нужно или даже можно. Но гипотетически это реальная ситуация и интерпретатор должен учитывать и такие случаи. Таким же образом в конструкторе может происходить всякая мракобесия (создание lock файла, запись в БД и прочие вещи, которых там не должно быть). Поэтому вырезать лишний код нужно крайне аккуратно.
Но за статью спасибо. Не так давно понял всю прелесть автоматических тестов. Когда выкатывание в продакшн почти перестало быть ритуалом. Полное покрытие кода всеми сценариями сделать очень сложно, но когда все основное проверено и хорошо работает, как-то крепче спится
Pipelines условно платная услуга. 50 минут в месяц может не хватить. Из этих соображений некоторые пилят свои велосипеды (как я и автор статьи).
Гитлаб хоть и бесплатный, но для него лучше купить второй сервер, чтобы сильно основной не нагружать. А, откровенно говоря, не все могут позволить себе иметь два сервера (как я и, возможно, автор статьи)
Но Вы абсолютно правы. Специализированные, изначально интегрированные и проверенные временем и тысячами разработчиками инструменты намного лучше и надежнее, чем подобные решения.
Там есть кастомные настройки, которые можно запустить вручную. Там в этом плане все достаточно гибко.
Насколько я знаю, запускается он только на последний коммит и только так, как настроишь. У нас, например, ветка master для разработки, которая ни на что не влияет. Там особо не нужно ничего запускать. А вот ветка release уже предназначена для кода в продакшн. Вот там вот уже и запускать тесты, сборку и прочее.
Я хочу сначала попробовать сделать так, чтобы все запускалось через pipeline, но работало как раньше, через веб-хуки. Если времени хватит, то перейдем в pipeline полностью. Или если начальство не по-жадничает $10 в месяц на дополнительные минуты)
Раньше тоже пользовался HipChat. Но столкнулся с проблемой, что на мобилках приложение не особо держится и вычищается. Из-за чего все уведомления пролетали мимо. Мы себе этого позволить не могли, так как в таких сообщениях могла содержаться очень важная на текущий момент информация. Что я только не делал (вроде там галочка была, чтобы он не терял соединение при сворачивании, но проблемы она не решала; это было давно, возможно, сейчас проблема исправлена). В итоге перешли в Slack. С тех пор таких проблем не наблюдалось.
Говоря про Bitbucket веб-хуки. Это хорошо, чтобы только уведомить сервер о том, что произошел пуш. И не более. У меня тоже происходила сборка по хуку, но продолжительность сборки была дольше, чем Bitbucket позволял мне, поэтому происходил timeout и еще две попытки, что запукало 3 сборки почти параллельно. Сейчас сделано так: веб-хук только записывает в файл, что произошло изменение (в моем случае пишет еще и в какую ветку, чтобы можно было собрать dev и release отдельно; у меня информация хранится в JSON массиве, чтобы если я запушил сразу в две ветки, прошло две независимых сборки). А по крону запускается ежеминутно скрипт, который и запускает сборку.
Сейчас в планах запуск тестов и сборку проекта перенести в Pipelines Это почти как CI, но попроще и интегрировано прямо в bitbucket. Там 50 минут в месяц бесплатно; для малых проектов хватит. Если хочется больше, то можно докупить 1000 минут за $10.
Безопасность, это другой вопрос (важный, но другой). Тут главное подход. И он, как мне кажется, более гибкий и универсальный, чем тот, который описан в статье.
Комментариев слишком много, может быть кто-то уже высказывал подобную мысль. Как вы думаете, такая схема не лучше:
Над вопросом безопасности, конечно, стоит подумать. Но польза от этого подхода в том, что не обязательно подтверждать вход с того же устройства. Залогиниться можно, допустим, на компе, а подтвердить на телефоне. Потом, клиентом может быть не только браузер, но и мобильное приложение или даже телевизор.
При запросе авторизации можно отправить либо тип клиента (web, mobile, tv), либо callback url, чтобы, если клиент — web или есть url, то показать кнопку, через которую можно вернуться на сайт.
Либо я неправильно настроил babel, но построчное выполнение кода внутри генератора вообще уводит куда-то в сторону (redux-saga). Если какая-то ошибка, никакие source-map'ы не помогают. Стектрейс вообще неадекватный в консоли.
Не так давно решил освоить FB. Все ты ничего, но "У вас новая рекомендация друга" по 15 штук не день в уведомлениях прям вымораживает. И не знаю как отключить. Гугл упорно молчит.
У меня немного другая идея. Декоратор bem работает не через аргументы рендера, а через пропсы:
А декоратор DI (или renderInjector) как раз запихивает аргументы в рендер:
Таким образом никто никому не мешает. И порядок в данном случае вообще не будет иметь значения.
Кстати говоря, мне нравится реализация react-bem-helper. Можете посмотреть. Хочу себе сделать такую же как у вас обертку в виде декоратора но с возможностями этого хелпера
```javascript
dic(DependencyOne, DependencyTwo)
@bemHelper('block-name')
```
Если не прав, поправьте, пожалуйста
Простите, цифры должны были идти по порядку, отредактировать уже не даёт. Поправьте, если кто может.
У React очень гибкое API. Можно легко перехватывать и переопределять свойства, как это делает, например, react-redux в декораторе connect. Поэтому и интересно, почему не пропсы?
Отличная идея проталкивать генератор bem классов с помощью декоратора. Сделаю у себя так. Но у меня несколько вопросов:
Использую Function bind transform:
К тому же иногда использую явный, ванильный биндинг:
Ой, простите…
Мне кажется, что в слове «людьми» должен стоять мягкий знак. Нарушаются правила русского языка.
(применение на практике)
Я тоже пишу код, как хочу, а потом нажимаю
Ctrl+Alt+L(В поиске: Reformat Code) и привожу его к общему стандарту. Помимо этого, PHPStorm неплохо синхронизируется с настройками.eslintrc.json.Тоже столкнулся с такой проблемой. Мне особенно нравится в 16-й версии, что в качестве рендера можно вернуть массив. Но не тут-то было. Одна из часто используемых библиотек, а именно react-bootstrap, не работает (не работала; сейчас не знаю) с новой версией React'a (проблема всплывает при использовании модальных окон)… Поэтому приходится пока что сидеть на последней 15-й версии.
Вообще может быть и такое:
Я не говорю, что так делать нужно или даже можно. Но гипотетически это реальная ситуация и интерпретатор должен учитывать и такие случаи. Таким же образом в конструкторе может происходить всякая мракобесия (создание lock файла, запись в БД и прочие вещи, которых там не должно быть). Поэтому вырезать лишний код нужно крайне аккуратно.