@Arris, вы не путаете функциональное с процедурным? ООП не ограничивает вас в применении парадигм функционального программирования. Более того, функциональное программирование не решает поставленных автором задач, но активно применяется внутри отдельных методов каких-либо классов.
По поводу "автоматизации разработки", вы перегибаете палку. С такими мыслями стоит отказаться от компиляторов и интерпритаторов, так как они автоматизируют и генерируют код за нас, когда мы пишем все на более приятных языках.
Да и потом, Бизнес-логику вам все-равно писать придется, а если при этом не придется писать кучу сервисного кода, то оно же хорошо. По поводу нового функционала, вы часто встречали проекты где требования и планирование нового функционала настолько далеко идут вперед, что можно за пол года предугадать развитие проекта? Я - нет. Частенько случается так, что требования к функционалу меняются уже вскоре после релиза очередной версии, что при сильной связанности системы превращается в очень трудозатратную задачу. С такими проектами проектировать систему с оглядкой на будущее становится просто нереально, и единственное что остается, проектировать систему так, что бы внесение изменений не вызывало много проблем. Это так же подразумевает юнит/интеграционное/функиональное тестирование что бы уменьшить количество регрессий и уменьшать задержки при доставке нового функционала.
Но никто конечно же не отменяет рационального мышления, программирование ради программирования тоже до добра не доводит. А "писать helloworld при помощи фабрик фабрик" попахивает нерациональным использованием инструментов.
С другой стороны, со всеми этими штуками аля PHP-DI, Composer, Symfony/HttpRequest, количество кода, позволяющее в кратчайшие сроки добавлять новый функционал, рефакторить не боясь регрессий, и в конечном итоге делать то, за что разработчику платят качественнее, снижают количество рутины при разработке и в конечном итоге и разработчик и клиент при грамотном подходе сохраняют больше нервных клеток за время разработки.
@zooks, а как правильно? Спрашиваю потому что ни разу не испытывал с этим проблем, раньше - да, а в последних версиях не особо, но хотелось бы знать когда будут проблемы.
@Arris, нет не кажется. Я за автоматизацию рутины. Если можно что-то не писать, я стараюсь этого не делать, а бутстраппинг компонентов движка дело довольно утомительное.
Можно конечно писать все как всегда, иметь жирные классы которые умеют много всего, иметь архитектуру при которой класс работы с базой умеет еще и валидировать данные... Если для вас цель просто написать проект и забыть, то ок. Но у проекта есть срок жизни, и скорее всего придется его рефакторить, добавлять новый функционал и много чего интересного. А есть еще штуки странные, как автоматизация тестирования, при котором штуки типа dependency onjection экономят массу времени и нервов.
Даже с точки зрения обучения - лучше сразу учиться правильным вещам.
@Winner777, ну так сделайте себе страничку с iframe-ами разных размеров и радуйтесь. Еще можно просто пару окон браузера открыть и лайв релоад подключить.
@Winner777, можно и в пикселях. Просто следует выкинуть из головы концепцию "одинаковой картинки". А по поводу адаптивной верстки - это да, нужно просто максимально продуктивно использовать доступное пространство.
@v0lume, он и не должен. В контексте ActiveRecord все это просто запихивается в DBCriteria или через create command. Наличие ORM не отменяет необходимости знать SQL.
@nepster09, видимо @zelenin говорит о GD. И да, для такой задачи смысла в этом ноль, лучше воспользоваться готовыми решениями а не пользоваться низкоуровневыми (а GD именно такое) API.
@hzd, md5 подходит только для верификации данных (быстрый и простой способ определить, поменялись ли данные).
В контексте безопасности, md5 даже для хэширования не подходит. То есть даже пароли лучше хэшить через sha512, причем в несколько сотен итераций и добавляя периодически соль.
Для шифрования можно использовать например openssl.
