Pull to refresh
1
0
Дмитрий @DmitryKm

Software Engineering Lead

Send message
Так я как раз и говорю о том, что фреймворки, в большинстве случаев, это целая база хороших практик и поэтому фреймворк мотивирует программистов писать правильно, красиво и учитывая все паттерны. Но, к сожалению реалии таковы, что программисты не учатся а только используют все out of the box.
Тем не менее когда люди спрашивают где им «учиться» хорошим практикам, мы частенько даем им изучать фреймворки.
Тут я не спорю, мой пост был просто о том, что нынешние фреймворки настолько упрощают жизнь, что многие программисты теряют мотивацию вылазить на уровень джуниоров.

Фреймворки — вещь отличная, но их использование должно мотивировать, а не тормозить саморазвитие.
Да, а потом когда билд красный и не явный — люди опускают руки и даже не знают с чего начать искать проблему. «Ведь мне обещали, что все будет работать»
Для небольших проектов использую:
Nginx + HaProxy

Также учитывая что все висит на DigitalOcean — переодически использую их Floating IP через API для быстрого перенаправления.
Звучит как отличное обновление! Я все еще склонен к симфони когда речь идет о большом проекте, но все мелкие-средние проекты теперь 100% буду писать на Laravel.

Единственное хочу отметить, тенденция фреймворков у которых почти 99% функционала идет out of the box ведет к тому, что люди пишут аппликухи быстрее, но не понимают как вещи работают under the hood. Идеальный пример — Java Spring. Провожу интервью по 3-4 человека в неделю, народ разворачивает API на Спринг буте за пару минут, но когда задаешь вопросы как работает @AutoWired или другие вещи — люди теряются и начинают рассказывать о черной магии…
Так а среднему бизнесу наоборот дешевле использовать облачные сервисы, тк скейлинг выходит намного дешевле. Вариант «Датацентр туда, датацентр сюда» доступен не многим)
Учитывая сколько сейчас гигантов перешло на облачный AWS — миф «Облака не годятся для бизнес-критичных приложений» уже давно умер.
Купил книжку, буду читать, надеюсь найду что-то интересное помимо обычной «технической» документации)
Полностью согласен, но опять же Symfony отлично славится своими компонентами :) Берешь Symfony Forms и используешь. Но естественно, должна быть граница и здравый смысл в выборе между использованием легкой библиотеки валидации и огромного компонента для форм от симфонии…
Тут надо смотреть как инициализируются правила. Если ты сам их инициализируешь и пихаешь в валидатор — то да, а если допустим ты просто передаешь кастомные рулсы в каком конфиге и они уже разворачиваются внутри валидатора — то тут уже не сработает.
Это если у тебя есть доступ к заполняемой форме внутри кастом правила :) Иногда правило — достаточно «изолирован» и не знает ничего кроме самого себя…
Не уверен, что это лучшее решение, но можно сделать форму где email не обязательное и вторую форму которая наследует первую и только переписывает правило для email. и когда человек сабмитит форму — в зависимости от логики — ты можешь создать нужную тебе форму и провалидировать ее.
Учитывая, что 90% моих проектов на Zend/Symfony, использую Zend\Validator, Symfony\Validator соответственно, особенно нравится Symfony вариант. Больше всего в их решениях привлекает тот факт, что валидация выглядит не отдельной библиотекой которую ты используешь, а интегрированным модулем который ты можешь использовать где угодно (валидация Entity, валидация форм и так далее).

Information

Rating
Does not participate
Location
Manchester, England - North West, Великобритания
Date of birth
Registered
Activity