Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 61
Тема перевода документации поднимается раз в 1-2 месяца, но каждый раз затухает, потому что коммюнити никак не может определится, есть ли в этом вообще смысл.
Доводы против:
* Перевод никогда не будет так же полон, как оригинал, потому что доки — не книга, они постоянно меняются и за этим не уследишь.
* Программист обычно и так владеет достаточным знанием английского
Что думает хабрачеловек по этому поводу?
Доводы против:
* Перевод никогда не будет так же полон, как оригинал, потому что доки — не книга, они постоянно меняются и за этим не уследишь.
* Программист обычно и так владеет достаточным знанием английского
Что думает хабрачеловек по этому поводу?
Документация на русском упростит старт новичкам. Стоит переводить, если есть желание.
Я знаю одного человека, который по даташитам английский выучил. С дикцией, конечно, ах, но зато всё понимает.
Симфони? Старт новичкам? Не смешите мои тапки :)
Отчего же? Ну займет старт не неделю а месяц. зато какой это будет продуктивный месяц для новичка.
Я считаю, что после изучения основ работы с php стоит переходить на изучение одного из широко используемых фреймворков. Symfony для этого вполне подходит.
Написать на Симфони2 говнокод так же просто как на голом PHP. Скажу более, симфони не продвигает принципы KISS и DRY в массы. Насчет, отсутствия KISS вы спорить со мной не будете, насчет DRY — попробуйте создать две формы для разных моделей с подобной логикой и добавить в каждую по одному одинаковому полю — напишите кучу копипасты.
Имхо, тот же Yii пока будет лучше, просто потому что он даст понятие о таких фреймворках как Rails, Django. В первую очередь нужен опыт, нужно виденье красивой и некрасивой реализации. А если сразу давать громоздкое ентерпрайз решение и не аргументировать его выбор, то разработчик просто не поймет — зачем оно.
Имхо, тот же Yii пока будет лучше, просто потому что он даст понятие о таких фреймворках как Rails, Django. В первую очередь нужен опыт, нужно виденье красивой и некрасивой реализации. А если сразу давать громоздкое ентерпрайз решение и не аргументировать его выбор, то разработчик просто не поймет — зачем оно.
В Symfony2 все очень даже по KISS, если сравнивать с конкурентами по нише.
Пример отсутствия DRY неудачен, я не верю что в том же Yii эту проблему можно решить без копипасты. Тут только трейтсы помогут.
Пример отсутствия DRY неудачен, я не верю что в том же Yii эту проблему можно решить без копипасты. Тут только трейтсы помогут.
В Symfony2 все очень даже по KISS, если сравнивать с конкурентами по нише.
Если конкуренты это Zend2, то да =)
Пример отсутствия DRY неудачен, я не верю что в том же Yii эту проблему можно решить без копипасты.
Почему? Значит пример работает ) Знаю как оно работает в симфони1, там был 1 класс отвечающий за формы. И если где-то бы дублировались поля, я бы мог это вынести в а) отдельный класс б) в родительский класс, и тп. Но в симфони2 форма это минимум 3 класса их расширять и поддерживать работы уже в 3 раза больше.
попробуйте создать две формы для разных моделей с подобной логикой и добавить в каждую по одному одинаковому полю — напишите кучу копипасты.
Создаю стандартный форм тайп и добавляю в опциях атрибут virtual. И… можно цеплять эту форму к любому объекту. Никакой копипасты. Архитектура форм в симфони довольно качественно продумана. Лучше я пока не встречал.
Думаю, что те, кто изучал в школе/универе английский язык, смогут без особого труда освоить официальную документацию. Ничего там сложного нет, все достаточно коротко и понятно написано.
Но судя по результатам опроса среди нас много либо людей с другим иностранным за плечами, либо тех, кому читать доки на русском все же привычнее. Каждому свое, как говорится!
Но судя по результатам опроса среди нас много либо людей с другим иностранным за плечами, либо тех, кому читать доки на русском все же привычнее. Каждому свое, как говорится!
Больше локализированной документации, хорошей и разной.
Ведь все равно, каков бы скилл английского не был, все равно лучше материал усваивается на родном языке. Поэтому лучше, чтобы был вариант выбора.
И вообще, наличие обширной русскоязычной документации чаще всего показывает уровень проникновения данной технологии в данной стране. «Взрослость» технологии.
Ведь все равно, каков бы скилл английского не был, все равно лучше материал усваивается на родном языке. Поэтому лучше, чтобы был вариант выбора.
И вообще, наличие обширной русскоязычной документации чаще всего показывает уровень проникновения данной технологии в данной стране. «Взрослость» технологии.
Ведь все равно, каков бы скилл английского не был, все равно лучше материал усваивается на родном языке.Вот на счет этого не совсем с Вами согласен. Мне намного комфортнее читать документацию подобного рода именно на английском и усваивать ее тоже в этом виде. В переводе бывает много неточностей или переведены те термины, которые не стоило бы переводить или переводить так, перевод далеко не всегда актуален… ну и т.д.
Поэтому лучше, чтобы был вариант выбора.Здесь несомненно, выбор это всегда хорошо. Как я уже говорил, люди все разные и усваивать информацию все могут по разному.
И вообще, наличие обширной русскоязычной документации чаще всего показывает уровень проникновения данной технологии в данной стране. «Взрослость» технологии.Достаточно субъективный показатель конечно, но в целом да, Вы правы.
Уточню, я ни в коем случае не против локализированных доков, но сам стараюсь использовать оригинальные варианты.
Да это как сесть за локализованную IDE — если какие-то трудности всё одно к англичанам обращаться придётся, а ты даже пункт меню назвать не можешь, не то что предложение сочинить. На быстрый старт ещё пойдёт, но углубляться уже не получится.
Если есть энтузиазм, то лучше писать туториалы и править основные доки, имхо.
1. Доки написаны очень доходчиво, не понятно чего там можно не понять
2. Много раз замечал в мейл-листе сифони, что глупые вопросы обычно задаются людьми с ломанным английским (глупые не в том смысле, что симфони не знают, а в том что… ну глупые), отсутствие перевода может хоть как-то отсеет таких.
3. Симфони такой фв в котором крайне желательно знание каких-то основных паттернов (не синглтон), а такие люди обычно и английский знают.
А главный довод — кому надо время на это терять? Если не жалко конечно, то вперед
2. Много раз замечал в мейл-листе сифони, что глупые вопросы обычно задаются людьми с ломанным английским (глупые не в том смысле, что симфони не знают, а в том что… ну глупые), отсутствие перевода может хоть как-то отсеет таких.
3. Симфони такой фв в котором крайне желательно знание каких-то основных паттернов (не синглтон), а такие люди обычно и английский знают.
А главный довод — кому надо время на это терять? Если не жалко конечно, то вперед
Полностью согласен.
Заодно чуть попиарю себя.
Вебинар по основам symfony2 habrahabr.ru/events/1365/
Он совсем бесплатный. Буду рассказывать про основы.
Надеюсь будет полезно сообществу.
Заодно чуть попиарю себя.
Вебинар по основам symfony2 habrahabr.ru/events/1365/
Он совсем бесплатный. Буду рассказывать про основы.
Надеюсь будет полезно сообществу.
Мануал переводить по-моему не стоит.
А вот чего имхо не хватает (новичкам особенно) это обновленного «jobeet» (не обязательно именно jobeet). Т.е. уроков создания (актуального) симфони приложения с большинством аспектов с нуля. Не хватает такого не то что на русском, даже на английском. В плане «как это сготовить, бро?»
А вот чего имхо не хватает (новичкам особенно) это обновленного «jobeet» (не обязательно именно jobeet). Т.е. уроков создания (актуального) симфони приложения с большинством аспектов с нуля. Не хватает такого не то что на русском, даже на английском. В плане «как это сготовить, бро?»
А вот тут совсем устаревшая hudson.su/symfony2/?
Хотя сам не читал русскую доку уже несколько лет, голосовал да. Перевод документации всегда полезное дело, начинаешь сам лучше понимать смысл происходящего. Так что если собрались переводить — переводите. Для себя точно будет польза.
Предлагаю организовать как форк официальной документации дабы любой желающий мог дополнять перевод.
Да есть уже, правда дико устаревшая github.com/avalanche123/symfony-docs-ru
Бегите с Симфони2! Бегите!
3 года разрабатывали на ZF. Решили 2 месяца назад перейти на симфони. Все свои наработки портировали, стали разрабатывать свои бандлы. И через 2 месяца терпение кончилось:
— миллионы классов
— не знаешь как написать, создавай сервис
— конфиги в разных местах
— чтобы найти или исправить ошибку, нужно минимум пол дня
Для себя прояснили:
— что стоимость разработки и поддержки на порядок выше,
— полно магии, да не просто магии, а чёрной магии, которая капитально связывает руки разработчикам
— документация хороша ровно до определенного момента, полно примеров, но как только нужно что-то похожее не из примеров, то документация этого не описывает и приходится лезть в исходники, чтобы понять как что-то реализовать
— DI и EventListeners это вроде бы клёво, но поверьте, дебаггинг с такими наворотами просто заставляет рвать волосы на голове, а если открыть чужой код, то он будет реально тяжел в понимании
Может быть использование только контроллеров и экшенов там удобно и те, кто этим ограничится будут счастливы.
Но только стоит начать писать свои бандлы, и ты понимаешь насколько больные явой люди писали этот код.
Чес слово, реальная ценность в простых вещах. К сожалению, у симфони её очень мало.
Дабы не портить свою жизнь, мы отказались от Symfony 2. И что ужасно — теперь не хотим возвращаться обратно в ZF.
Сейчас с PHP в тестовом режиме переходим на Ruby. В рельсах тоже много магии, но надеемся, что она будет белой.
3 года разрабатывали на ZF. Решили 2 месяца назад перейти на симфони. Все свои наработки портировали, стали разрабатывать свои бандлы. И через 2 месяца терпение кончилось:
— миллионы классов
— не знаешь как написать, создавай сервис
— конфиги в разных местах
— чтобы найти или исправить ошибку, нужно минимум пол дня
Для себя прояснили:
— что стоимость разработки и поддержки на порядок выше,
— полно магии, да не просто магии, а чёрной магии, которая капитально связывает руки разработчикам
— документация хороша ровно до определенного момента, полно примеров, но как только нужно что-то похожее не из примеров, то документация этого не описывает и приходится лезть в исходники, чтобы понять как что-то реализовать
— DI и EventListeners это вроде бы клёво, но поверьте, дебаггинг с такими наворотами просто заставляет рвать волосы на голове, а если открыть чужой код, то он будет реально тяжел в понимании
Может быть использование только контроллеров и экшенов там удобно и те, кто этим ограничится будут счастливы.
Но только стоит начать писать свои бандлы, и ты понимаешь насколько больные явой люди писали этот код.
Чес слово, реальная ценность в простых вещах. К сожалению, у симфони её очень мало.
Дабы не портить свою жизнь, мы отказались от Symfony 2. И что ужасно — теперь не хотим возвращаться обратно в ZF.
Сейчас с PHP в тестовом режиме переходим на Ruby. В рельсах тоже много магии, но надеемся, что она будет белой.
Как минимум в рельсах больше документации. Магии там конечно больше, но она не ради магии, а для компактности и эффективности
Подозреваю что вы и про руби через 2 месяца будете тоже самое говорить =)))
Везде есть свои особенности.
— про «миллионы классов» и «конфиги в разных местах» — это вам надо перейти на какую-нибудь удобную IDE, я вот пользуюсь sublime text 2(jetbrains rubymine тоже умеет быстро открывать любые файлы даже в самых больших проектах) и от количества файлов в любом проекте на любом ЯП никакого дискомфорта не испытываю
— про создание сервисов там более чем достаточно документации и после написания первого обработчика событий все вопросы по их созданию отпадают совсем, лично мне нравиться как там сделана работа с сервисами через DIC
— про исправление ошибок, опять же у вас недостаточно опыта в Symfony, если вспомните как вы начинали работать с ZF, думаю у вас были похожие ощущения. А уж когда вы сейчас сунетесь в руби, сомневаюсь что вы будете чужие ошибки быстрее исправлять, тут ещё важно степень погружения в фреймворк.
«Чёрная магия» там есть, в частности связана с авторизацией, я разбирался несколько дней, зато после того как разобрался отпали все вопросы по работе с сервисами, роутингом и.т.п.
Про «лезть в исходники» — покажите мне ЛЮБОЙ фреймворк или CMS, где не нужно лезть в исходники? Я таких за свою жизнь не встречал совсем, любая более менее нестандартная задача и вечер в тоннах кода обеспечен(а исходники у symfony 2 не чета остальным, очень аккуратные и понятные).
В общем, я считаю что вы в чём-то недоразобрались и необъективны.
А symfony 2 на мой взгляд очень хорошо написанный фреймворк, гибкий и быстрый который разрабатывает команда профессионалов + там собраны отличные иструменты(лучше их шаблонизатора по умолчанию twig я ни в одном языке программирования не видел, monolog — очень достойный продукт для логгирования с поддержкой firePHP из коробки и.т.п.), у них САМАЯ лучшая среди других фреймворков панель для отладки + понятный и простой способ для её самостоятельного расширения. Правда для работы с ним нужно достаточно глубокое понимание ООП и некоторое терпение поначалу + умение читать документацию (и читать вдумчиво).
Везде есть свои особенности.
— про «миллионы классов» и «конфиги в разных местах» — это вам надо перейти на какую-нибудь удобную IDE, я вот пользуюсь sublime text 2(jetbrains rubymine тоже умеет быстро открывать любые файлы даже в самых больших проектах) и от количества файлов в любом проекте на любом ЯП никакого дискомфорта не испытываю
— про создание сервисов там более чем достаточно документации и после написания первого обработчика событий все вопросы по их созданию отпадают совсем, лично мне нравиться как там сделана работа с сервисами через DIC
— про исправление ошибок, опять же у вас недостаточно опыта в Symfony, если вспомните как вы начинали работать с ZF, думаю у вас были похожие ощущения. А уж когда вы сейчас сунетесь в руби, сомневаюсь что вы будете чужие ошибки быстрее исправлять, тут ещё важно степень погружения в фреймворк.
«Чёрная магия» там есть, в частности связана с авторизацией, я разбирался несколько дней, зато после того как разобрался отпали все вопросы по работе с сервисами, роутингом и.т.п.
Про «лезть в исходники» — покажите мне ЛЮБОЙ фреймворк или CMS, где не нужно лезть в исходники? Я таких за свою жизнь не встречал совсем, любая более менее нестандартная задача и вечер в тоннах кода обеспечен(а исходники у symfony 2 не чета остальным, очень аккуратные и понятные).
В общем, я считаю что вы в чём-то недоразобрались и необъективны.
А symfony 2 на мой взгляд очень хорошо написанный фреймворк, гибкий и быстрый который разрабатывает команда профессионалов + там собраны отличные иструменты(лучше их шаблонизатора по умолчанию twig я ни в одном языке программирования не видел, monolog — очень достойный продукт для логгирования с поддержкой firePHP из коробки и.т.п.), у них САМАЯ лучшая среди других фреймворков панель для отладки + понятный и простой способ для её самостоятельного расширения. Правда для работы с ним нужно достаточно глубокое понимание ООП и некоторое терпение поначалу + умение читать документацию (и читать вдумчиво).
P.S. а ещё мне очень нравится их компонент работы с формами, я писал один проект с большим количеством форм и решил как-то себе работу с ними упростить и начал писать класс для их генерации. Написал некоторое количества кода и поймал себя на мысли что я же готового ничего не посмотрел. Просмотрел кучу говнокода на эту тему и в конце концов зашёл на сайт симфони и прочитал про их компонент… я был в шоке, ибо у них было всё что мне нужно (даже намного больше) уже оттестировано и готово к эксплуатации, более гибкого и удобного инструмента для генерации форм я пока тоже не встречал. А уж когда я увидел их профайлер я понял что это любовь навеки, хе-хе )))
Да вы правы, симфонийские формы очень удобны и круты.
Их гораздо удобнее расширять чем ZF. Zend_Form полная какашка, так же как и Zend_Db.
Во всех планах Symfony 2 сейчас впереди всех php-шных фреймворков.
Их гораздо удобнее расширять чем ZF. Zend_Form полная какашка, так же как и Zend_Db.
Во всех планах Symfony 2 сейчас впереди всех php-шных фреймворков.
Я рад что у вас получилось подружиться с Symfony2.
Просто мы видимо слишком много от нее требуем, и мало хотим ей отдавать, и у нас любовь с Symfony2 не сложилась.
Просто мы видимо слишком много от нее требуем, и мало хотим ей отдавать, и у нас любовь с Symfony2 не сложилась.
Вообще, тема не для этого создавалась, поэтому не совсем понимаю зачем вы это все затеяли, но тут не удержусь.
Поделитесь, что ж вы такое большое делаете, что Symfony2 не справляется?
Для справки, точно знаю что на Symfony2 есть или разрабатывается:
* CRM для банка
* Платежная система
* Админка у крупного облачного хостинга
* Портал с 100+ млн просмотров в день
* Аукцион с огромным количеством форм и фильтров
Просто мы видимо слишком много от нее требуем
Поделитесь, что ж вы такое большое делаете, что Symfony2 не справляется?
Для справки, точно знаю что на Symfony2 есть или разрабатывается:
* CRM для банка
* Платежная система
* Админка у крупного облачного хостинга
* Портал с 100+ млн просмотров в день
* Аукцион с огромным количеством форм и фильтров
Я говорю не про производительность работы скриптов на серверах. Симфони в продакшене показывает оличную скорость.
Я говорю про удобство работы программистов с фреймворком, про стоимость разработки на нём и стоимости поддержки. Про то насколько сложно будет ввести в курс дела нового программиста.
Если честно, то мы ужасно намучились за 2 месяца разработки на ней. На ней нереально сложно разрабатывать свои бандлы.
Я говорю про удобство работы программистов с фреймворком, про стоимость разработки на нём и стоимости поддержки. Про то насколько сложно будет ввести в курс дела нового программиста.
Если честно, то мы ужасно намучились за 2 месяца разработки на ней. На ней нереально сложно разрабатывать свои бандлы.
Не понял, по вашему в вышеперечисленных проектах не имеют значения удобство работы программистов с фреймворком, стоимость разработки/поддержки и насколько сложно будет ввести в курс дела нового программиста?
Ага, настолько сложно, что уже почти 2000 их. И не надо опять заводить песенку про малые требования…
На ней нереально сложно разрабатывать свои бандлы
Ага, настолько сложно, что уже почти 2000 их. И не надо опять заводить песенку про малые требования…
У меня на привыкание ушел месяц. Время разработки на симфони примерно такое же как и на других фреймворках, с которыми я работал. А вот в плане поддержки все намного более приятно.
Тьфу-тьфу-тьфу, пожалуйста не накаркайте :) про то, что через 2 месяца мы будем то же самое говорить про руби. Нам надо выпустить проект в январе.
— про удобные редакторы:
Нас три человека, и у каждого из нас свой «любимый» редактор IDE: Eclipse, NetBeans, SublimeText2. Поэтому нет никаких проблем в работе с кодом. Просто лишком навернутое абстрагирование классов друг от друга. С одной стороны это огромный плюс для Симфони, но и в то же время минус (в голове всё удержать тяжело).
— про сервисы:
Проблем с написанием сервисов никаких. Просто при разработке аналогичного друпаловскому модулю — Content Construction Kit (CCK) нам пришлось навернуть порядка 20 сервисов для того, чтобы обеспечить работу параметров через стандартный механизм форм и валидации. Сколько в итоге для всего этого написали классов тяжело поддаётся подсчёту. Безумный симфонийский уровень абстракции начал играть с нами — просить написать пару тройку классов для одной задачи.
— про ошибки:
Самая основная проблема в том, что в режиме разработчика приходится долго ждать пока сгенерится страница. Сделал опечатку, жди 10-40 секунд пока прогрузится страница. Подправил, в другом месте ошибка — опять жди. Понятно, что в продакшене всё это дело будет быстро работать, но в dev режиме скорость работы просто ужасна.
Да вы правы про то, что мы недоразобрались. Но сколько уже можно разбираться?!
Поэтому с тем, что мы необъективны я с вами не соглашусь. Для меня объективно важна скорость ввода нового человека в проект. К сожалению, всё достаточно сложно (да вроде всё логично и понятно, НО в голове приходится держать слишком огромную модель взаимосвязей). А сам фреймворк должен помогать, а не мешать.
Честно, когда я увидел описание симфони, попробовал квик-старт — я был впечатлен. Мне все очень понравилось. И понравился отладчик и магия DI. Это казалось очень простым и удобным функционалом. Потом мы заюзали композер, прикрутили Capifony, жизнь разработчика, как бы стала ярче. Теперь для разворачивания новой версии на продакшене занимало всего одну команду. Все было круто, симфони ушел намного вперёд по сравнению с остальными фреймворками.
Прошло время, и мы стали понимать, что фреймворк тормозит нашу работу. По первой, мы думали, что просто стары стали. Что надо перестраивать мозг. Потеряли хватку. Что вот-вот и придёт прозрение. Что ещё чуть-чуть и нирвана поглотит нас. В какой-то момент у нас одновременно у троих лопнуло терпение. Сели, поговорили, и вынесли для себя вердикт — спрыгнуть побыстрее со всей этой магии, абстракции и модульности. Мы потеряли контроль, контроль над ошибками, контроль над определением сроков.
— про удобные редакторы:
Нас три человека, и у каждого из нас свой «любимый» редактор IDE: Eclipse, NetBeans, SublimeText2. Поэтому нет никаких проблем в работе с кодом. Просто лишком навернутое абстрагирование классов друг от друга. С одной стороны это огромный плюс для Симфони, но и в то же время минус (в голове всё удержать тяжело).
— про сервисы:
Проблем с написанием сервисов никаких. Просто при разработке аналогичного друпаловскому модулю — Content Construction Kit (CCK) нам пришлось навернуть порядка 20 сервисов для того, чтобы обеспечить работу параметров через стандартный механизм форм и валидации. Сколько в итоге для всего этого написали классов тяжело поддаётся подсчёту. Безумный симфонийский уровень абстракции начал играть с нами — просить написать пару тройку классов для одной задачи.
— про ошибки:
Самая основная проблема в том, что в режиме разработчика приходится долго ждать пока сгенерится страница. Сделал опечатку, жди 10-40 секунд пока прогрузится страница. Подправил, в другом месте ошибка — опять жди. Понятно, что в продакшене всё это дело будет быстро работать, но в dev режиме скорость работы просто ужасна.
Да вы правы про то, что мы недоразобрались. Но сколько уже можно разбираться?!
Поэтому с тем, что мы необъективны я с вами не соглашусь. Для меня объективно важна скорость ввода нового человека в проект. К сожалению, всё достаточно сложно (да вроде всё логично и понятно, НО в голове приходится держать слишком огромную модель взаимосвязей). А сам фреймворк должен помогать, а не мешать.
Честно, когда я увидел описание симфони, попробовал квик-старт — я был впечатлен. Мне все очень понравилось. И понравился отладчик и магия DI. Это казалось очень простым и удобным функционалом. Потом мы заюзали композер, прикрутили Capifony, жизнь разработчика, как бы стала ярче. Теперь для разворачивания новой версии на продакшене занимало всего одну команду. Все было круто, симфони ушел намного вперёд по сравнению с остальными фреймворками.
Прошло время, и мы стали понимать, что фреймворк тормозит нашу работу. По первой, мы думали, что просто стары стали. Что надо перестраивать мозг. Потеряли хватку. Что вот-вот и придёт прозрение. Что ещё чуть-чуть и нирвана поглотит нас. В какой-то момент у нас одновременно у троих лопнуло терпение. Сели, поговорили, и вынесли для себя вердикт — спрыгнуть побыстрее со всей этой магии, абстракции и модульности. Мы потеряли контроль, контроль над ошибками, контроль над определением сроков.
На самом деле истина одна — не использовать новые технологии там где есть жёсткие сроки, если вы перепрыгните на Ruby не думаю что ситуация сильно улучшится, проекты со сроками надо делать на том, в чём есть опыт, пусть даже и с неудобными технологиями.
P.S. по поводу производительности в dev режиме: а вы APC или какой-нибудь другой кеш опкода используете? Опять же метаданные доктрины(если её используете) можно (и нужно) кешировать.
P.P.S. А про ООП — я уже несколько раз менял полностью подход к созданию классов (после «банды 4х», Фаулера и Эрика Эванса) и пришёл к выводу что чрезмерная абстракция сразу не нужна, она должна появлятся там, где вы делаете бандл «для других людей» (не из вашей команды) или если точно известно что она нужна (такое не часто бывает).
P.S. по поводу производительности в dev режиме: а вы APC или какой-нибудь другой кеш опкода используете? Опять же метаданные доктрины(если её используете) можно (и нужно) кешировать.
P.P.S. А про ООП — я уже несколько раз менял полностью подход к созданию классов (после «банды 4х», Фаулера и Эрика Эванса) и пришёл к выводу что чрезмерная абстракция сразу не нужна, она должна появлятся там, где вы делаете бандл «для других людей» (не из вашей команды) или если точно известно что она нужна (такое не часто бывает).
если вы перепрыгните на Ruby не думаю что ситуация сильно улучшится, проекты со сроками надо делать на том, в чём есть опыт, пусть даже и с неудобными технологиями.
никогда не слышал, чтобы руби называли неудобной технологией :)
Опять же метаданные доктрины(если её используете) можно (и нужно) кешировать.
Угу, вот только доктрина якобы сама умеет кешировать данные в дев режиме, но пишет по 1 аннотацию на файл. В итоге подгрузка всех файлов очень тормозит проект, и даже рефлексия, может быть была бы эффективнее. Кеширование метаданных в файлах релизовано крайне неэффективно. А ставить APC для дева — имхо, излишество.
чрезмерная абстракция сразу не нужна
угу, но почему-то симфони её провоцирует
никогда не слышал, чтобы руби называли неудобной технологией :)
Да я не про Ruby, а абстрактно, просто если переходят на новые технологии, значит старые чем-то не устраивали…
Угу, вот только доктрина якобы сама умеет кешировать данные в дев режиме, но пишет по 1 аннотацию на файл.
Я такого в документации не видел, а в prod режиме эти параметры по умолчанию закомментированы.
А ставить APC для дева — имхо, излишество.
Ускорение работы разработчика излишество? Я что-то недопонимаю в этой жизни, видимо… О_о
P.S. я даже без симфони всегда использовал APC, потому что при минимуме настроек даёт невероятную пользу.
угу, но почему-то симфони её провоцирует
Несмотря на это в любом процессе должен преобладать здравый смысл.
Да я не про Ruby, а абстрактно, просто если переходят на новые технологии, значит старые чем-то не устраивали…
Ну почему-то народ уходил я Явы и дот Нета на РНР. Хотя, блоги и на Яве делать можно было, зачем Вордпресс нужен?
Я такого в документации не видел
Кто в документацию смотреть будет? Это в профайлере такое есть. И в коде доктрины, если что.
Касательно кеширования метаданных, в дев режиме не особо интересовался, но в prod все замечательно. По поводу загрузки большого количества файлов, это все кешируется каждый раз, и полный ребилд кэша обычно вызывается редактированием основных конфигов. А так ребилд идет только локальный и много времени не занимает, да и вы можете сами поведение настроить. в prod режиме же симфони использует bootstrap.php.cache в котором содержатся все необходимые классы (файл собирается при установке/обновлении зависимостей, ну и можно руками попросить перестроить). Да и использовать APC стоит. Как минимум ускоряется работа системы без особых жерств.
«А ставить APC для дева — имхо, излишество.»
Это все проясняет. Как говорится ССЗБ.
“If you care about performance and don’t use a bytecode cache then you don’t really care about performance. Please get one and start using it.”
Stas Malyshev, Core Contributor to PHP and Zend Employee
Это все проясняет. Как говорится ССЗБ.
“If you care about performance and don’t use a bytecode cache then you don’t really care about performance. Please get one and start using it.”
Stas Malyshev, Core Contributor to PHP and Zend Employee
Мы не спорим о необходимости байкод кешера. Просто на деве мы не боремся за высокую скорость работы. Просто хочется, чтобы оно работало нормально. Но 10-30 секунд это не нормально.
Так с использованием APC таких задержек и нет, в том-то и прикол. У меня во всех проектах dev 200-1400 мс. И это вполне приемлимая скорость.
Такие цифры у меня были только под Windows. Debian + APC (в виртуалке) — в среднем в dev окружении 0,5-2 секунды. Иногда бывает по 10 но только если поправил конфиг и кэш чиститься по сути полностью.
Угу, но ужас, я работаю на виндовс. Просто многие задачи (фотошопы всякие) тут делать удобнее. И расизм по ОСям я не приемлю.
О ужас, я тоже работаю под WIndows. (причем на 8-ке, на 7-ке таких дикий проблем с производительностью не наблюдалось. хотя я не особо много усилий прилагал что бы их исправить. Как потом оказалось даже на виртуалке все выполнялось в 4 раза быстрее, потому собственно так теперь и работаю. IDE в шиндовсе, окружение в виртуалке. Файлы проектов расшарены через Samba, но я еще думаю поэксперементировать с coLinux и еще с парой плюшек).
p.s. Расизм по ОСям это вообще глупо, тут спорить с вами я не буду. Но факт есть факт, PHP отрабатывает медленно (не все, только регулярные выражения, функция file_exists и ресолвинг DNS (хотя последнее обходится очень легко).
p.s. Расизм по ОСям это вообще глупо, тут спорить с вами я не буду. Но факт есть факт, PHP отрабатывает медленно (не все, только регулярные выражения, функция file_exists и ресолвинг DNS (хотя последнее обходится очень легко).
Win8/WAMP, 1500 мс на довольно тяжелой странице. Что я делаю не так?
Я вроде очень неплохо знаю английский язык, но мне всвегда приятнее читать на русском.
Мир многолик, и не надо его упрощать. Мир говорит на разных языках, и потому документации тоже должны быть на разных языках. Посмотрите, сколько официальных языков у ООН или у Евросоюза!
Конечно, удобно вести документацию на одном языке — трудоемкость ниже, но за этим следует глобальный проигрыш, ведь язык — это способ думания, и с сокращением многообразия способов думания мир станет плоским :-(, исчезнут краски.
Так что я за перевод.
Конечно, удобно вести документацию на одном языке — трудоемкость ниже, но за этим следует глобальный проигрыш, ведь язык — это способ думания, и с сокращением многообразия способов думания мир станет плоским :-(, исчезнут краски.
Так что я за перевод.
Уже давно подбираюсь к симфони. Ковыряю ее в перерывах между проектами, пытаюсь понять. Т.к. я в универах программирование не учил, мне очень сложно разобраться в этой среде, но я вижу ее красоту, и понимаю, что, освоив ее, я сильно повышу свой уровень, и приучу себя к дисциплине. Отсутствие документации на русском языке конечно сильно меня тормозит. Отсутствие какого-либо symfony-комьюнити тоже. Надеюсь, что ее таки переведут, хотя, к тому времени, это врядли будет мне нужно. Но это приведет много новичков в эту среду, они тоже будут отучаться от быдлокодерства и повышать свой уровень. Думаю, что дело это благое.
К сожалению набыдлокодить на симфони не зная самых основ очень даже легко. Убедился в этом на практике разгребая код за одним чудом-юдом.
Быдлокодить конечно хорошо, и, по началу, даже нужно, но потом приходит понимание как то же самое можно реализовать гораздо изящнее, и смысл быдлокодинга пропадает.
Быдлокодинг хорошо лечится через ревью кода.
На этапе обучения не имеет значения как ты пишешь свой hello world. чем больше граблей, тем больше вникаешь в ситуацию. Выпускать такое в мир конечно нельзя. Поэтому я еще не сделал ни одного рабочего проекта под Symfony. Схожу на вебинар, послушаю. Вообще я ужасно рад, что зарегался на хабре. Здесь полно толковых людей с умными мыслями.
symfony.com.ua
ещё не всё переведено, но уже много
ещё не всё переведено, но уже много
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Нужна ли вам документация Symfony2 на русском?