Эх, вот вроде бы статья написана не плохо: структурировано, с примерами, последовательно. Но действительно ли стоило 50% информации посвящать созданию проекта в гитлабе, установке git, созданию ключей, ...?
Это же основа основ, и если кто-то не может справится с такими вещами, то зачем ему CI/DI? Имхо, но планка хабра все таки чуть выше. Может стоило более детально рассмотреть варианты runner'ов гитлаба, показать примеры использования разных подходов к CI/DI через Gitlab, расписать преимущества, недостатки, сложности и подходы к их решению.
Думаю, что это просто один из подходов решения проблемы, а уж что использовать — выбирает каждый сам для себя. Мне тоже ближе использовать замыкания, чем рефлексию, не потому что быстрее или еще что-либо, а просто потому что больше нравится запись.
Вряд ли такое кто-то будет осознанно использовать в работающем коде, но при тестировании часто встречается ситуация, где не плохо было бы либо прочитать значение из скрытого поля или наоборот туда что-либо записать.
p.s. Да-да, я знаю, что если очень хочется так сделать, то что-то не так с архитектурой и тестировать надо публичный контракт класса, а не его кишки, но жизнь штука многогранная и иногда приходится делать и такие трюки.
Пакет у Symfony может работать только с CLI SAPI, данная утилита прекрасно дружит с php-fpm + умеет в https и привязку доменов. Кроме этого, локальная разработка лишь 30% функционала этой утилиты, большей частью она была создана для управления проектом связке локальная разработка + prod в symfony clouds, там много интересных плюшек по клонированию окружения проекта из prodа в локальный dev и тд. Подробнее можно в презентации Фабиена посмотреть symfonycasts.com/screencast/symfonycon2018/back-to-basics
Это тоже не совсем верно. Например, если у нас стоит задача запустить dns-сервер, то его можно запустить на FreeBSD 4.10 и он может 20 лет прекрасно работать. Просто работать и все. Возможно, за 20 лет понадобится что-то обновить один раз. Если мы говорим про софт в формате, что мы запустили и он реально много лет работает без каких-то обновлений, без внесения изменений, то, конечно, там не будет Kubernetes. Он там не нужен.
Имхо, на текущий момент самый главный конкурент kubernetes — его отсутствие. Многие вещи сейчас реализуются без него удобнее и быстрее. И его задача сейчас реализовать максимально гибкий, удобный и универсальных подход infra as service для всех. Как только это случится, то на open source наработках появятся конкуренты, который будут реализовывать +- аналогичные вещи.
В целом, интересная заявка на будущее инфраструктуры.
Очень ждал продажи elephpant'ов на PHPRussia, но к сожалению, был только их розыгрыш. Это наверное можно отнести к единственному недочету конфы (если закрыть глаза на микроскопические туалетные кабинки и их кол-во:) ).
Проверил, действительно. Очень неожиданное и непонятное поведение. Надо попробовать отписать им в баг-трекере. Именно управление правами в целом ни к чему, но вот удалять канал должен явно либо админ, либо его создавший.
Там есть настройка Mark Channel Unread, ее нужно включить в Only for mentions и тогда чат не будет помечаться непрочитанным, кроме случаев, когда вас по нику зовут.
Тоже искали альтернативу Слаке, Рокет показался крайне глючным при первом знакомстве. В итоге остановились на about.mattermost.com. Пока более чем устраивает.
Так и есть, затычка в большом количестве расшареных файлов. На макоси все решил проброс файлов в виртуалку через nfs. На Windows долго не сидел конечно, но сходу решения найти не удалось.
Про это не знал, спасибо. Но в моем случае это бесполезно, так как хотелось универсализировать окружения разработчиков, сидящими под разными ОС, в том числе windows. С docker-machine уж больно все медленно выходит.
Эх, вот вроде бы статья написана не плохо: структурировано, с примерами, последовательно. Но действительно ли стоило 50% информации посвящать созданию проекта в гитлабе, установке git, созданию ключей, ...?
Это же основа основ, и если кто-то не может справится с такими вещами, то зачем ему CI/DI? Имхо, но планка хабра все таки чуть выше. Может стоило более детально рассмотреть варианты runner'ов гитлаба, показать примеры использования разных подходов к CI/DI через Gitlab, расписать преимущества, недостатки, сложности и подходы к их решению.
Катаюсь на ней каждый день без нарушений. Ускорение — да, а скорость можно и контролировать.
А заодно и организацию, в которой кроме как IE8 благодаря политикам ты использовать ничего не сможешь :)
Думаю, что это просто один из подходов решения проблемы, а уж что использовать — выбирает каждый сам для себя. Мне тоже ближе использовать замыкания, чем рефлексию, не потому что быстрее или еще что-либо, а просто потому что больше нравится запись.
Вряд ли такое кто-то будет осознанно использовать в работающем коде, но при тестировании часто встречается ситуация, где не плохо было бы либо прочитать значение из скрытого поля или наоборот туда что-либо записать.
p.s. Да-да, я знаю, что если очень хочется так сделать, то что-то не так с архитектурой и тестировать надо публичный контракт класса, а не его кишки, но жизнь штука многогранная и иногда приходится делать и такие трюки.
Тот же google.com резолвится далеко не в один адрес и его резолв зависит от многих факторов. Как DPI поймет правильный он или нет?
Например, запросы с личного компа во Владимире и с сервера в Москве
Извините, а зачем через сокеты запрашивать что-то с фронта, если бэк сам может послать уведомление об окончании обработки?
Это если его декларировать
function myMethod(): ?SomeType;, если его опуститьfunction myMethod();то метод по прежнему может возвращать что угодно.Вполне годна штука, если нет желания возиться с докером для локальной разработки.
Имхо, на текущий момент самый главный конкурент kubernetes — его отсутствие. Многие вещи сейчас реализуются без него удобнее и быстрее. И его задача сейчас реализовать максимально гибкий, удобный и универсальных подход infra as service для всех. Как только это случится, то на open source наработках появятся конкуренты, который будут реализовывать +- аналогичные вещи.
В целом, интересная заявка на будущее инфраструктуры.