Выбор первого фреймворка

Проблема многих, кто еще не пробовал. В сети множество различных фреймворков: Zend, CodeIgniter(его тут часто советуют), Cake PHP и др. Я просто не знаю, какой попробовать, да и ошибиться не хочется. А времени на выбор 2-3 дня. Всех их попробовать я не успею.
Просто недавно начал на ООП писать, и велосипед создавать не охото. Говорят, фреймворки облегчают жизнь (на какой-то промежуток времени ), поэтому мне интересны все ваши советы.
Плюс еще такой момент не понятен. Я редактирую библиотеки, со временем, пишу свои дополнительные методы и прочее. А потом версия фреймворка обновляется и что? Вся работа на смарку? Или надо все время наследников делать?

-----
In Console We Trust. Code hard. Or die.

Ну к примеру, у меня есть собственная библиотека, основанная на Zend и призванная облегчить работу с бизнес-логикой (своего рода ORM общего вида). И - да, при обновлении библиотеки некоторые вещи нужно переписывать, чтобы идти в ногу со временем. Но кардинальные изменения происходят не так уж часто, чтобы сильно усложнять работу.

По поводу фреймворка - наверное, именно тот, "самый первый", который Вы будете изучать, и положит основу понимания и концепции собственно фреймворка как такового. Поэтому я не вижу смысла начинать с чего-либо "попроще", чтобы потом перейти на что-то другое. Не нужная трата времени и сил. Как сторонник Zend рекомендовал бы его. Почему? Вопрос хороший, и ответ на него неоднозначен. Во-первых, он исходит непосредственно от разработчиков PHP. Во-вторых, качество и количество документации и примеров могут дать фору многим другим известным фреймворкам. В-третьих, имеет большое количество уже реализованных в своих библиотеках функциональностей.
В качестве альтернативы можно посмотреть Symfony2 - но здесь я не советчик, мне не довелось глубоко изучать этот фреймворк.

-----
Есть в мире две бесконечные вещи - это Вселенная и человеческая глупость. Но насчет первой .. я не уверен.

EuGen
и как понять, что где-то там в коде произошло обновление N-метода, например?

-----
In Console We Trust. Code hard. Or die.

кстати да, товарищ EuGen вещает хорошую мысль в том плане, что первый каркас заложит весьма глубого понимание принципов программирования как такогого и тут действительно, чем менее адекватный каркас будет выбран, тем сложнее в последующем может оказаться жизнь ;))

по личному опыту, документацию достаточно подробно читал практически по всем каркасам (да время позволяло), но выбор сделал в сторону Symfony2 и сейчас именно его и штудирую... скажу сразу, если у вас время на принятие решения 2-3 это еще ладно, но если у вас и время на разработку проекта на будучи выбранном каркасе будет тоже измеряться парой-тройкой недель, тогда симфони скорее всего не подойдет факт в том, что освоение сф2 никому недаётся с наскоку т.к. в нём применяется несколько интересных передовых решений и каждое из них надо освоить, только после этого работа пойдет более менее предсказуемо ;)

что касается "изменений", то сф2 очень серьёзно спроектирован и надобности изменять именно его код почти не возникает, все задачи бизнес логики решаются наследованием.

CI - он самый простой
как раз для начинающих

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

еще он очень быстрый и немного попахивает говнокодом. Он на РНР5 еще не переписан

Для этого существует официальный сайт. При новом релизе все изменения будут указаны. Ну и СКВ, разумеется. Если Вы получаете обновления из главной стабильной ветки - то при очередном обновлении все сами увидите.

-----
Есть в мире две бесконечные вещи - это Вселенная и человеческая глупость. Но насчет первой .. я не уверен.

Начал пробовать Zend. Сразу понравился магазин (http://shop.zend.com/), ребята прям как Red Hat - "хотите конфетку? придется заплатить". И в туториалах сразу рекламируют свой сервер, показывают, как создать проект и т.д. Регаетесь, получаете плюшку, а потом - "Valid until: 04 Oct 2012". Все четко.
А не кажется ли вам, что разработчик, использующий тот или иной фреймворк, платит сильной привязкой к этому продукту? В один прекрасный момент "они" скажут, что "ребят, мы вот посовещались и решили, что далее все будет платным, спасибо за участие, оставайтесь с нами". И юзеры останутся со старым продуктом в приятном смятении.
Я за СПО и мне не понять данную стратегию. Да, они делают отличные библиотеки, продумывают структуру всего и много-много других подводных камней, и писать свои библиотеки, это, конечно, моветон, но зато вы точно уверены в завтрашнем дне, вы точно знаете свой код, вы быстро в нем разбираетесь и модифицируете его.
Да, Zend шикарен, я пришел к такому выводу после прочтения http://habrahabr[dot]ru/post/31168, как и все разработчики, они показывают нам "свой путь", то есть "как надо", как должно быть, свое видение, так сказать. На одной из конференций Убунты (я не помню, может и не убунты) Томас Твейт показал презентацию, как он разобрал тостер, а затем сделал свой. Да, ему это обошлось недешево, в плане запчастей, и он потратил больше времени, изобретая свой велосипед. Может это плохой пример, но в СПО как раз свой велосипед изобретать не стоит, на то оно и СПО. Вы пользуетесь техническим прогрессом и достижениями тех или иных людей, связанных с разработкой.
Применительно к фреймовркам, я считаю, это недостаточно удобно - вы должны быть полностью погружены в конкретный вами выбранный продукт, "тостер". Методы, классы и прочее. Томасу достаточно было понять структуру, как работает тостер, для создания своего он использовал детали, которые он мог купить в ближайшем магазине. И он был полностью независим от кампании N, которые эти тостеры выпускала. + Он мог в любой момент модифицировать этот тостер, например, увидев то, что ему казалось неприемлемым, можно было поменять, на то, что подходило именно ему.
Да, тостер - это не ПО. Но написав свое ПО, вы можете спать спокойно - любую ошибку или уязвимость при обнаружении вы легко устраните.
Сегодня я был на конференции "Математические проблемы современной теории управления системами и процессами". Там был очень интересный доклад о супер компьютерах, их использовании и так далее. Когда разработчики представляли свое ПО (которое производит различные мат. расчеты, где нужно +64 процессора) заказчикам - разным нефтяным, авиационным кампаниям, последние требовали, чтобы ПО было не "самописное", а лицензированное, которое используется ведущими фирмами, стабильно и практично. И это понятно, заказчик хочет быть уверен в том, что разработчик в своем ПО не допустил ошибки, пусть лицензионные продукты стоят 3-5млн. рублей в год, но зато существует гарантия, что продукт надежен и сделан профессионалами. (А главное - иностранцами. )
Это печально, ведь те же самые разработчики широко известных программных продуктов, тоже могли допустить ошибку, которую потом быстро зафиксят - это же их работа. Я замечаю такую же ситуацию и в веб-разработке. Практически у каждой вакансии в описании есть галочка - "желательно знание N фреймворка". Возвращаясь к тем программистам, которые писали ПО для супер компьютера. Есть ли бы не желание заказчика, то можно было точно также развивать то самое ПО, адаптировать его именно под нужные задачи, например, моделирование выкачивания нефти с глубины 2-3 км (на самом деле, это целая наука, поверьте), в конце концов, лицензировать его и выйти на мировой рынок. Но дядям, которые платят, это не надо, точнее их интересует только свой бизнес и чтобы "все работало", а работает "при использовании N-продукта".
Да, я привел 2 довольно-таки спорных примера - создание собственного тостера и разработкой ПО. Проблематика у них общая - мы используем не свои продукты, не свои идеи, а заимствуем их, прикрываясь изречениями вроде "это прогрессивные методы, их надо использовать". При этом мы не поддерживаем те же самые идеи наших соотечественников, пусть вы написали свою CMS и выложили ее на гитхаб, все равно, на работе вас заставят использовать N, так как "она надежнее, ее делали умные люди".
Я считаю, что разработчик должен делать сам, на то он и разработчик. Выбор фреймворка - да, дело каждого, "удобный инструмент" и так далее. Но вы не идете дальше, вы используете готовую структуру, например, контроллер, вид, модель, потому что она зарекомендована и вроде как идеально правильна.
"Перед разработкой N, когда я впервые столкнулся с поставленной задачей, я смотрю, как делают другие. Просматриваю множество идей, уже готовых решений и выбираю из них самое лучшее..." - так, наверно, каждый разработчик может сказать про себя, все мы с этого начинали. А кто может продолжить: "... а потом, на основе всего мне понравившегося и своего опыта, я делаю свой вариант, по-моему мнению идеально подходящий для данной задачи, в который включаю свои идеи и делаю его по той структуре, какой я ее вижу."? Если вы юзаете фреймворк, мне кажется, вторая часть уже невозможна. Вы же используете чужой каркас. Сегодня я понял, что когда все смотрят направо, полезнее всего смотреть налево, а именно напоминать, что мы разработчики, инженеры, технари. Мы должны придумывать свои "скелеты" и идеи, продвигать их и воплощать в жизнь. Сейчас не про использование того или иного продукта, полезность его использования и прочее, так как каждый выбирает сам, и все что я написал - это только моя извращенная точка зрения. Я вижу здесь много профессионалов своего дела, почему они не хотят собраться вместе и сделать что-то наше, русское, конкурентоспособное, чтобы остальной мир понял, что мы тоже, не только потребители, что нам есть, что показать?
Написано много, какой вывод сделать для себя - каждый определится сам. Может, я ошибаюсь, и все, что я написал - полнейшая чушь.

-----
In Console We Trust. Code hard. Or die.

очень точное замечание ;)) я уже давно пытаюсь найти единомышлениика... глухо... сейчас изучаю Symfony2, почти в одиночку... затяжное это занятие, когда один... есть еще идейка "побаловаться" и написать "микро-фреймворк" ;)) типа Silex, Slim и т.д... основной особенностью видится отсутсвие статических методов ;) а вообще если есть другие предложения - пишите! я всегда открыт на контакт ;)

digi
у меня, к сожалению, не такой большой опыт в разработке(6 месяцев), чтобы писать фреймворк. Однако, я написал диплом, где программная реализация на php, вот мараю электронные листы в libre office.
Причем в 2ем мы далеко не уйдем, для такой задачи нужен коллектив единомышленников, сообщество со своими идеями. Продукт, над которым будет затрачено много человеко/часов должен будет иметь ясные отличия, плюсы, которых нет у конкурентов. А чтобы сделать такое, нужен опыт.

-----
In Console We Trust. Code hard. Or die.

Статья как бы старинная.


Если продукт стоит этого, то пользователи будут платить. Если нет, то перейдут на другой фреймворк.

А вообще не понятен ваш подход к выбору фреймворка. Вы вопрос ставите таким образом, что фреймворк выбирается один раз и на всю жизнь. Почему нельзя попробовать несколько фреймворков? Почему, вы боитесь изучить лишний фреймворк? Даже если вы потом будете использовать только один какой то фреймворк, знание других фреймоворков очень пригодится. Вам будет с чем сравнивать и вы не будете всё время думать, что на другом берегу рыбы больше.

всё равно с чего-то надо начинать ;) под лежачий камень вода не течет ;)

что именно сделать?
русских фреймворков и CMS полно.

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

Ch_chov
дело не в фреймоврках. дело во времени и профите, КПД, так сказать.
digi
можно начать со систематизации всех возможных приемов и фич для конкретных областей в конкретной системе. То есть своего рода "пособие для умных", которые содержит в себе приемы и идеи, которые стоит применить каждому в своем проекте, ну или просто для развития, чтобы юзер мог "прокачать" свой скилл.
Проблема в том, что люди пишут отличные статьи, приводят примеры решений отдельных ситуаций, как они с ними справились и так далее. И вся эта информация раскидана по сети, она написана на разных языках, но все-таки находится в открытом доступе.
Собрать их в одном месте, пусть даже на вики движке, не туториалы и маны, например, как сделать график, а именно нестандартные идеи - наверно, у каждого они есть. Да даже и стандартные - все равно будет полезно, если кто-то выложит свой класс, свой метод, другой изменит, оптимизирует, предложит другой вариант реализации - тогда уже будет база, на которой можно начинать "что-то конкурентоспособное"

-----
In Console We Trust. Code hard. Or die.

в CI есть некоторые хорошие идеи, но тот факт что там все повязано на магических методах (или чет типа того) что не позволяет в полной мере исопльзовать IDE жутко тормозит разработку, есть правда для этого некий коделобстер, но мне он не привычный.