Комментарии 24
Хех, развёрнутый ответ на мой вчерашний вопрос и собственно для работы с этим фреймворком вопрос и задавался :) Спасибо
Я искренне рад что вам попался заказчик который хочет делать проект на Symfony2 да еще и готов платить на платный github аккаунт. Побольше бы таких :)
От symfony2 я его честно отговаривал :)
Symfony2 это круто. Есть такая конторка knpLabs. Среди их проектов шахматы [github lichess] и symfony2bundles [github s2b]. В общем крутые ребята и проекты, есть чему поучиться. Они в основном на Sf2 прогают.
Можете повторить аргументы, если не трудно? Спрашиваю потому, что сам хочу заказать проект на symfony2.
Основной аргумент — достаточно сырой код, который, вероятно, ещё не раз будет подвергаться рефакторингу, включая крупные изменения API (такие как переименования классов, перенос свойств/методов и т. п.). По крайней мере, я за неделю уже столкнулся с тем, что с переход от PR2 к PR3 был не безболезненный. Есть баги, которые сложно вылавливать, т. к. довольно много сгенерированного кода, который непонятно где (если только начал работать с фв) генерируется.
Второй — в связи с тем, что фреймворк в активной стадии разработки документации нормальной нет, а та что есть частично «out of date», как пишут в рассылке. То есть разработчику сложно будет использовать фреймворк как «чёрный ящик», надо будет подробно изучать его код, а где-то он будет изобретать велосипед, то есть реализовывать уже реализованные, но ещё не документированные возможности.
Ну и третий, как следствие первых два, увеличенное время разработки, как в связи с постоянными изменениями самого фреймворка (вы же не хотите, чтобы в вашем проекте была не самая свежая версия фв, которую, в том виде, в котором она есть, возможно исправлять никто не будет), так и в связи с тем, что разработчика хорошего знакомого с фв вряд ли найдёте, а значит время на изучение ему потребуется (оплачивать или нет это время — есть разные точки зрения, лично я считаю, что если на знакомом фреймворке проект можно написать за месяц, а на незнакомом за два, то оплата должна быть как за 1,5 месяца :) — компромисс между желаниями разработчика и заказчика).
Есть и плюсы: фреймворк реально шустрый; «тру» архитектура и самого symfony2 и дефолтной орм(sql СУБД)/одм (nosql — сейчас только mongodb, но мне её с лихвой хватает :) ) doctrine (используются многие паттерны архитектуры enterprise приложений, навскидку — сервисы, фабрики, единица работы, репозитории, инъекции зависимостей и т. д.), а значит модификация кода будет происходить довольно быстро; ориентирован на активное использование DDD, TDD и т. п.
В общем рекомендовал бы пока только для проектов, которые зарелизятся к концу года (когда должен выйти релиз symfony2), а то и позже, и сроки не жмут. И обязательно требовать от разработчика покрытия его кода тестами близкого к 100% (как минимум, 100% кода взаимодействующего с фреймворком), чтобы при изменении в API все проблемные места моментально выявлялись и исправлялись, поскольку из документации сейчас, по сути, только комментарии к коммитам
P.S. И тут Остапа понесло :)
Второй — в связи с тем, что фреймворк в активной стадии разработки документации нормальной нет, а та что есть частично «out of date», как пишут в рассылке. То есть разработчику сложно будет использовать фреймворк как «чёрный ящик», надо будет подробно изучать его код, а где-то он будет изобретать велосипед, то есть реализовывать уже реализованные, но ещё не документированные возможности.
Ну и третий, как следствие первых два, увеличенное время разработки, как в связи с постоянными изменениями самого фреймворка (вы же не хотите, чтобы в вашем проекте была не самая свежая версия фв, которую, в том виде, в котором она есть, возможно исправлять никто не будет), так и в связи с тем, что разработчика хорошего знакомого с фв вряд ли найдёте, а значит время на изучение ему потребуется (оплачивать или нет это время — есть разные точки зрения, лично я считаю, что если на знакомом фреймворке проект можно написать за месяц, а на незнакомом за два, то оплата должна быть как за 1,5 месяца :) — компромисс между желаниями разработчика и заказчика).
Есть и плюсы: фреймворк реально шустрый; «тру» архитектура и самого symfony2 и дефолтной орм(sql СУБД)/одм (nosql — сейчас только mongodb, но мне её с лихвой хватает :) ) doctrine (используются многие паттерны архитектуры enterprise приложений, навскидку — сервисы, фабрики, единица работы, репозитории, инъекции зависимостей и т. д.), а значит модификация кода будет происходить довольно быстро; ориентирован на активное использование DDD, TDD и т. п.
В общем рекомендовал бы пока только для проектов, которые зарелизятся к концу года (когда должен выйти релиз symfony2), а то и позже, и сроки не жмут. И обязательно требовать от разработчика покрытия его кода тестами близкого к 100% (как минимум, 100% кода взаимодействующего с фреймворком), чтобы при изменении в API все проблемные места моментально выявлялись и исправлялись, поскольку из документации сейчас, по сути, только комментарии к коммитам
P.S. И тут Остапа понесло :)
Вы не правы. Со следующей недели основную часть фактически «заморозят». twitter.com/fabpot/statuses/24460327693
Документация уже приличная, это трудно назвать черным ящиком. docs.symfony-reloaded.org/?page=learn
Соответственно третий пункт отпадает.
Документация уже приличная, это трудно назвать черным ящиком. docs.symfony-reloaded.org/?page=learn
Соответственно третий пункт отпадает.
Я начал проект до «релиза» PR3, соответственно после него кое-что сломалось (хотя кое что и заработало :) ) и в тот момент когда в разделе «get the code» были ссылки на сэндбокс PR2 (который явно был с багами, например работа с аннотациями в одм), кое-что из этих доков не работало (в частности получение данных из репозитория орм было не совсем корректно и 3 дня назад я этот вопрос поднимал в рассылке, а сегодня смотрю доки поправлены :) ) и с переходом на PR3 пришлось свои исходники править кое-где. А под чёрным ящиком я имел в виду как раз хорошую документацию, чтобы у разработчика приложения не было необходимости лезть в код фреймворка — есть описания входа и выхода, внутрь лезть незачем, мне же приходилось, поскольку даже сгенерированный автоматически код содержал ошибки
Сейчас ещё вычитал:
>The final release is planned for March 2011
:(
>Keep in mind that Symfony2 is still a moving target and things break from time to time.
Выделено мною
>The final release is planned for March 2011
:(
>Keep in mind that Symfony2 is still a moving target and things break from time to time.
Выделено мною
НЛО прилетело и опубликовало эту надпись здесь
Приватный аккаунт стоит денег. Чтоб код никто не скопировал.
На bitbucket.org (меркуриал), на сколько я знаю, 1 приватный аккаунт бесплатно дают.
На bitbucket.org (меркуриал), на сколько я знаю, 1 приватный аккаунт бесплатно дают.
простите, а что за шрифт на картинке?
Начались недели VCS на хабре :)
а можно подробнее что после clone делать? из гайда не ясно зачем мы скачали symfony-sandbox и что с ним делать дальше %)
Топик написан для тех, кто хочет стартануть проект на Symfony2.
Логичнее всего развернуть sandbox и начать активно в нем все менять, добавлять (все кроме фв и модулей типа Doctrine). В процессе разработки приложения, Symfony2 будет меняться независимо от вас. И в посте описан один из путей как поддерживать фв и сам проект в актуальном состоянии.
После clone, когда вы развернули субмодули… разрабатывать нужный вам функционал. И не забывать обновлять фв с компонентами.
Логичнее всего развернуть sandbox и начать активно в нем все менять, добавлять (все кроме фв и модулей типа Doctrine). В процессе разработки приложения, Symfony2 будет меняться независимо от вас. И в посте описан один из путей как поддерживать фв и сам проект в актуальном состоянии.
После clone, когда вы развернули субмодули… разрабатывать нужный вам функционал. И не забывать обновлять фв с компонентами.
Один вопрос. Например у меня есть свой проект. Я хочу подключить ZF, его нужно подключать просто положив директорию Zend в Library. Но сама библиотека находится не в корне git репозитория. В SVN это решалось просто выбором нужного пути из репозитория. Как это в git получить?
Я понял вы хотите использовать в качестве субмодуля не весь репозиторий, а только одну из директорий (чтоб корнем субмодуля была например папка library/Zend).
Я сейчас еще разбираюсь, так не делал, но думаю нужно использовать механизм subtree merge. Вот еще пост на хабре в тему.
Тут наверное просто не совсем субмодуль нужно использовать, так как папка .git находится только в корне репозитория (в отличие от svn). Если продвинусь, еще напишу.
Я сейчас еще разбираюсь, так не делал, но думаю нужно использовать механизм subtree merge. Вот еще пост на хабре в тему.
Тут наверное просто не совсем субмодуль нужно использовать, так как папка .git находится только в корне репозитория (в отличие от svn). Если продвинусь, еще напишу.
Ссылка протухла github.com/guides/developing-with-submodules =\
да, это есть… не знаю зачем они его убрали, был отличный гайд
Там не это было? help.github.com/split-a-subpath-into-a-new-repo/
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Организация работы с git submodules