Комментарии 102
Не холивора ради, но если симфони1 вдохновлялся Ruby on Rails, то симфони 2 скорее ближе к джаве. Преимущество RoR подхода мне кажется в его лаконичности, преимущество джавы — гибкости и расширяемости. Т.е. как по мне, в чистом виде, симфони подходит для энтерпрайз-приложений, но не «сваять сайт», «сделать блог», «сделать свою социальную сеть», короче, не для стартапов. Ибо стартапы имеют ограниченные ресурсы и все эти неймспейсы, аннотации, конфиги это то что отвлекает от самой разработки.
В моем понимнии, симфони2 это отличный каркас для некого нового фреймворка, который бы объединял простоту symfony1/ror и мощь symfony2. Но к сожалению, пока таких не видно и думаю, ближайший год не будет. Потому, чисто по параметрам стабильность, документированость, юзабилити я предпочту пока Rails. Для личных разработок.
В моем понимнии, симфони2 это отличный каркас для некого нового фреймворка, который бы объединял простоту symfony1/ror и мощь symfony2. Но к сожалению, пока таких не видно и думаю, ближайший год не будет. Потому, чисто по параметрам стабильность, документированость, юзабилити я предпочту пока Rails. Для личных разработок.
Уже есть например silex. Собранный на основе компонент symfony. Интересная штука.
Да, направление правильное, разработчики симфони сами намекают на то, что хотят, чтобы был новый фрйемворк на основе симофни2. Сами они называют симфони2 метафреймворком. Но пока это Синатра-клон, он нацелен на свои задачи и для массового использования не годится.
Что за феерический бред? Где мы такое говорили? Symfony2 не годится для стартапов? shopopensky.com/, www.exercise.com/, jirafe.com/. И это учтите, что Symfony2 еще даже не в RC цикле!
Ну ты же сам работал с рельсами и работал с симфони2. Я лишь высказал мнение, что рельсы пока что выглядят лучше и дружелюбнее для разработки. И по сути это не в упрек симфони2, просто ему пока не хвтает некого более дружественного интерфейса в обертке над нынешнем. Более мощный аутолоадер, меньше конфигов, больше генераторов, и т.п. Например, я бы хотел верить, что с выходом Propel2 симфони даже превзойдет Rails.
Как можно сравнивать дружелюбность фрэймворка, уже имеющего 3 отстабиленные ветки с тем, который еще даже в RC ни разу не переходил (symfony1 и Symfony2 — абсолютно разные продукты)? И вот да, так документация и конвенции по Symfony2, отличны, понятны и дружелюбно, несмотря на постоянный WIP
Почему нельзя сравнивать? Из религиозных убеждений? Это всё веб-фрейимворки, на всех из них можно написать блог. Просто фичи для упрощения разработки пока даже не аннонсируются в симфони, потому мое мнение, скоро появится новый фреймворк типа Silex, но что-то более мощное, объединяющее простоту RoR и symfony.
Не анонсируются фичи для упрощения? Правда? Мне опять кинуть ссылку на блог? Возможно просто не по той модели упрощения, которую хотели бы вы лично. Но поверьте мне, мы работаем именно над теми конвенциями, которые упростят жизнь PHP-разработчикам, а не тем, кому хочется RoR, но лень учить Ruby.
Не смотря на почти нулевые знания руби я в рельсы въехал за день (при этом копая доки по самому руби), а симфонии (2) я испугался. Нутром понимаю что вроде чуваки правы и делают правильно, но посмотрев на простейшие вещи понимаю, что до юзабилити рельсов им еще далеко. За основу можно брать любой компонент, хоть модель, хоть контроллер, хоть вьюхи, хоть роутинг. Про бандлы вообще молчу.
Бандлы, правды ради, не столько заслуга Рельс, сколько Руби. Bundler просто удачно применил механику gem-ов.
Впрочем, я сейчас осознал, что, возможно, отсутствие этой кучи статичного кода, тоже заслуга Руби.
Впрочем, я сейчас осознал, что, возможно, отсутствие этой кучи статичного кода, тоже заслуга Руби.
При чем тут руби? Разве только то, что на нем написаны рельсы… Никто не мешает сделать такой же простой конфиг и юзать его. Если у симфонии будут плагины «хорошо лежать», то никто не мешает их так же ставить.
Да и по поводу статичного кода…
@posts = Post.find;
$this->posts = Post::find();
вместо
$em = $this->get('doctrine')->getEntityManager();
$posts = $em->getRepository('AcmeDemoBundle:Post')->findAll();
return array('posts' => $posts);
Да и по поводу статичного кода…
@posts = Post.find;
$this->posts = Post::find();
вместо
$em = $this->get('doctrine')->getEntityManager();
$posts = $em->getRepository('AcmeDemoBundle:Post')->findAll();
return array('posts' => $posts);
Да, с примером согласен на все 100%. Доподлинно неизвестно, зачем заставлять писать пользователя такое количество ненужного кода. К примеру добавлю сложность описания моделей.
Вот потому я верю в успех Propel2, правда я думал, что будут развивать Doctrator, но он как-то заглох. Доктрина в чистом виде тоже метафреймворк, хотелось бы всё-таки хоть какой-то ActiveRecord. Тем не менее, она чуть более стабильна первой доктрины, и не «течет», как делала первая.
Вообще слово «верю» это круто. Не, правда. Можено сидеть и верить, что когда-то это станет крутым и прикольным. Вот тока проблемка одна есть… Писать то сейчас нужно :)
DataMapper(+UnitOfWork) более продвинутый паттерн, чем ActiveRecord. Но, да, даже Фаулер считает, что его применение не всегда лучший выход. Для CRUD он явно излишен, его преимущества чувствуются на более сложной бизнес-логике.
Модели описывать элементарно — простой «Plain Old PHP object» — разрабатывать и тестировать модель предметной области одно удовольствие. Запарно описывать мэппинг этой модели на базу данных.
Symfony2 cmf запланирован давно, но я от него чего-то особенного не ожидаю, т.к. участники пока своими работами (включая упоминаемую в посте ужаснейшую ФосЮзерБандлу) далеко не блещут. Вообще из всех лежащих в открытом доступе на гитхабе бандл мне пока понравилась только WhiteOctoberAdmin, которая, несмотря на зачаточное состояние, уже дает возможностей больше чем админ-генератор s1 и крайне проста.
Что же касается сложности, имхо для «простого блога» не нужно юзать рельсы, а достаточно вордпресса с миллионом написанных плагинов и доступных для найма индусов. А для любого приложения, которое хоть как-то планирует расширяться и масштабироваться, спрингово-симфонийский подход гораздо лучше.
Что же касается сложности, имхо для «простого блога» не нужно юзать рельсы, а достаточно вордпресса с миллионом написанных плагинов и доступных для найма индусов. А для любого приложения, которое хоть как-то планирует расширяться и масштабироваться, спрингово-симфонийский подход гораздо лучше.
PHP вообще тяготеет к Java в последнее время и Фабиену это, похоже, нравится :) А так согласен, симфони2 с её модульностью, DI и т. п., больше подходит для долговременных сложных проектов, чем для «здесь и сейчас».
Но вот с прогнозом, думаю, немного ошибаетесь. По-моему, перспективы у симфони выйти на «здесь и сейчас» никак каркас для какого-то другого единого каркаса, а в виде основы для многочисленных «сборок», решающих конкретные задачи.
Но вот с прогнозом, думаю, немного ошибаетесь. По-моему, перспективы у симфони выйти на «здесь и сейчас» никак каркас для какого-то другого единого каркаса, а в виде основы для многочисленных «сборок», решающих конкретные задачи.
Я и подразумеваю, что должен быть новый фреймворк, который позволяет писать на симфони маскимально лаконично и эффективно. Вполне возможно, это и будет некая такая сборка. Но, например, собрать полезные бандлы и выкатить это как сборку, каркас для проекта, этого будет немного маловато. С точки зрения архитектора это будет выглядеть хорошо, а с точки зрения разработчика он не поймет, почему, например, столь необходимо писать \Entities\User, Symfony\Controller, короче, использовать всю строгость именований. Для 90% случаев она не нужна.
Не нужна — не используйте. Пишите контроллеры и ентити в глобальный неймспейс и наслаждайтесь этим, если вам действительно кажется, что отсутствие неймспейсов сколь-нибудь ускорит вашу разработку.
Блин, ну неужели не очевидно о чем я говорю? О сложности писать все эти строгие конструкции. И ускорить разработку скорее поможет выбор другой платформы )
Вас НИКТО не заставляет их писать! Вам быстрее все накидать в 1 неймспейс или даже файл? Кидайте! Все будет работать.
Ок, если мои слова понять трудно, попытаюсь объяснить, что имелось ввиду с помощью ссылки:
propel.posterous.com/the-end-of-autoloading
propel.posterous.com/the-end-of-autoloading
Француа не программист, о чем он сам ни раз повторял (точнее он говорил, что он ужастный программист). И как не-программисту, ему сложно понять некоторые концепции программирования. Француа менеджит разработку пропела, но код пишут немного другие люди ;-)
Ага, отличный ход в споре — указать на ничтожность оппонента.
Вы прибегли к ссылке на пост автора, оперирующего своими личными ощущениями к теме дискуссии. Я обратил ваше внимание на то, что личные ощущения ДАННОГО автора могут сильно расходиться с ощущениями и потребностями РЕАЛЬНЫХ разработчиков, о которых мы ведем речь.
Ок, я тоже нереальный. Другие разработчики, которые не согласны с вашей политикой тоже нереальны?
Вы переводите разговор в сферу личностных восприятий. Я не делю программистов на реальных/нереальных по признаку принятия/непринятия моей точки зрения. Но я называю программистом лишь того, кто пишет код и пишет его профессионально. Тот, кто код не пишет или писать его красиво не умеет (по его собственному признанию), не является программистом и, соответственно, не может целостно определить что для программиста лучше, а что хуже. Вот и все. Политика тут не при чем. Приведите другой пример или сформулируйте свою собственную точку зрения.
Есть сотни других ПРАВИЛЬНЫХ и КРАСИВЫХ моделей разработки помимо рельс. Свыкнитесь с этим, как свыклись коры Symfony2 ;-) Большинство проблем первой симфонии появились как раз от того, что симфония пыталась походить на рельсы, но PHP — это ни разу не Ruby. И да, по объектной модели, PHP ближе к Java, чем к чисто-объектному Ruby. Это ни хорошо, ни плохо — это просто так!
Ну да, рельсы просто помогают делать сложные вещи простыми, это мне и нравится. А вот модель делать простые вещи сложными, совершенно не нравится. Неужели это мнение столь дикое, что должно обязательно оспариваться?
Я оспариваю ваши личностные предположения о том, что Symfony2 априори развивается по пути усложнения жизни разработчиков и процесса разработки.
Я привел примеры 3 активно-разрабатывающихся стартапов на Symfony2, не имеющих проблем со сложностью разработки или понимания самого процесса разработки программистами. Вы, напротив, делаете выводы, о сложности и удобстве Symfony2, основываясь лишь на том, что она не похожа на RoR.
Я привел примеры 3 активно-разрабатывающихся стартапов на Symfony2, не имеющих проблем со сложностью разработки или понимания самого процесса разработки программистами. Вы, напротив, делаете выводы, о сложности и удобстве Symfony2, основываясь лишь на том, что она не похожа на RoR.
Блин, а в чем мы эффективность меряем? А её ни в чем пока не измерять, она может быть только личным ощущением. Я вот чувтствую, что тот же блог с фичами, я напишу на симфони1 и рор быстрее, чем на симфони2, даже если дать 3 дня форы на полноценное изучение документации. Я не оспариваю, что на симфони2 можно разрабатывать, и что он хорош. Блин, сколько можно повторять, что симфони2 настолько классная шутка, что поверх него, вполне можно написать свои рельсы, как уже написан свой Sinatra. Зачем тогда спорить? Я прекрасно понимаю, что обе модели разработки имеют право на жизнь. Почему не хочешь понять этого ты?
Затем, что «симфони2 настолько классная шутка, что поверх него, вполне можно написать свои рельсы», «для массового использования не годится» и т.п. являются голословными утверждениями, основанными на личностном отношении и непонимании субъекта обсуждения. Да, Symfony2 очень расширяем. Да, код в нем больше похож на Java, чем на Ruby. Но НЕТ, не нужно сверху ничего напиливать, чтобы он был прекрасным средством для разработки. Для блога он не сильно подходит, конечно. Как не подходят для этого и рельсы! Но если очень хочется — и на том и на том можно БЫСТРО, КРАСИВО, КАЧЕСТВЕННО написать блог. Только для начала нужно изучить тул, с которым будешь работать — будь то RoR или Symfony2.
Количество любви и обожания к Симофни2 тут явно обратно пропорционально адекватности высказываемого.
Сам я всё сказал. Dixi.
Сам я всё сказал. Dixi.
Скорость и качество разработки на знакомом фремворке явно выше, чем на незнакомом. Я даже не знаю, зачем было оглашать эту аксиому.
Речь, как я понял, идет лишь об излишнем нагромождении действий и кода, необходимых для решения элементарных задач. Если для получения результата нужно ручками написать 20 строк вместо 3х, то это восторга не вызовет, как вы ни расхваливайте удобство и элегантность этих 20ти строк. Краткость — сестра таланта.
Речь, как я понял, идет лишь об излишнем нагромождении действий и кода, необходимых для решения элементарных задач. Если для получения результата нужно ручками написать 20 строк вместо 3х, то это восторга не вызовет, как вы ни расхваливайте удобство и элегантность этих 20ти строк. Краткость — сестра таланта.
Большинство проблем первой симфонии
А можно в двух словах о проблемах? Интересно.
Они как я понял так и хотят делать — distributions, просто пока со стабильностью не закончат — до этого видимо не доберутся.
Аннотации как раз и введены, чтобы упростить разработку, причём они опциональны. Не совсем понял про неймспейсы — как они могут отвлекать от разработки? Да и по поводу ресурсов — symfony2 куда менее требовательна к ресурсам по сравнению 1.
Аннотации — отлично. Но по сути вместо аннотаций мы пишем конфигурацию. Они могут быть гораздо лаконичнее, вот и всё. Я считаю, что аннотации это путь в будущее, но они должны легко запоминаться и легко писаться. Без всяких ужасных префиксов.
Да прочитайте вы хотябы оффициальный блог прежде чем делать какие-либо выводы или ставить утверждения: symfony.com/blog/symfony2-annotations-gets-better
Прикинь, читал. Суть поста в том, что мы сделали аннотации более длинными, чтобы вам было легче писать. Ну или вы можете вгружать неймспейсы. Я не говорю, что это неправильно. Просто это неудобно. Usability, ага?
Да поймите вы наконец, Usability !== МалоБуков! Порой легче написать и осознать 3 логичных слова, чем из раза в раз пытаться запомнить 1 нелогичное!
Пытаться запоминать все варианты префиксов для каждого типа объектов — ужасно, нелогично, неудобно. Делать все аннотации глобальными — ужасно для дебага и расширяемости.
Да, нужно написать полный неймспейс класса с аннотацией, но после этого вы сознательно понимаете:
1) Как вызывать остальные аннотации
2) Где смотреть код аннотации
3) Как добавить свою
Вот это — usability, а не что-то из области «меньше букв», «меньше нажатий»
Пытаться запоминать все варианты префиксов для каждого типа объектов — ужасно, нелогично, неудобно. Делать все аннотации глобальными — ужасно для дебага и расширяемости.
Да, нужно написать полный неймспейс класса с аннотацией, но после этого вы сознательно понимаете:
1) Как вызывать остальные аннотации
2) Где смотреть код аннотации
3) Как добавить свою
Вот это — usability, а не что-то из области «меньше букв», «меньше нажатий»
/**
* @Route("/:id")
* @Cache(smaxage=«15»)
*/
public function showAction(Post $post)
{
}
Разве это не удобно?
FrameworkExtraBundle, экспериментальная фича. Но кто его знает что будет на момент релиза.
* @Route("/:id")
* @Cache(smaxage=«15»)
*/
public function showAction(Post $post)
{
}
Разве это не удобно?
FrameworkExtraBundle, экспериментальная фича. Но кто его знает что будет на момент релиза.
Вот это как раз удобно. Только насколько быстро аннотации будут работать?
На сколько я понимаю в symfony все кешируется.
Понятно вообщем. Люди вам сейчас будут пересказывать документацию Symfony2, а вы будете задавать все новые и новые вопросы, прекрасно описанные в ней ;-)
Все в Symfony2 КЕШИРУЕТСЯ. Включая прочтенные аннотации!
Все в Symfony2 КЕШИРУЕТСЯ. Включая прочтенные аннотации!
Миш, быстро они работают. Можно самому проверить :)
Меня честно говоря напрягает обилие возможностей для конфигурирования. Никак не могу остановиться на одном способе. Вроде бы аннотации смотрятся лаконично, но для config их использовать нельзя. XML вообще правильный формат, но по читабельности сильно проигрывает (именно читать конфиги неудобно, валидация по XSD рульная вещь, прямо на уровне IDE). Ну и т.д.
Аналогично не холивара ради.
Извините, не знаком с Симфони, но если аннотации введены, чтобы упростить разработку, то что же было до них?
Просто на протяжении чтения статьи не покидал опрос «Почему нужно выполнять столько действий? Зачем писать столько кода? Это же Симфони!» До этой статьи искренне считал Симфони нечто богоподобным, составляющим конкуренцию Рельсам.
Извините, не знаком с Симфони, но если аннотации введены, чтобы упростить разработку, то что же было до них?
Просто на протяжении чтения статьи не покидал опрос «Почему нужно выполнять столько действий? Зачем писать столько кода? Это же Симфони!» До этой статьи искренне считал Симфони нечто богоподобным, составляющим конкуренцию Рельсам.
Косательно аннотаций модели, в symfony1 (а если быть точнее, то в doctine1) были отдельные файлы схем config/doctrine/schema.yml. В symfony2 точно так же можно описать всё в одном файле app/config/mapping.orm.yml.
Субъективно, 3 рhp-файла по 20 строк и 2 шаблона это не так уж и много кода для функционала блога. Единственное, чего нет в symfony2, так это admin generator'a из symfony1. C ним бы не пришлось создавать и эти файлы. Возможно, скоро и этот функционал появится в виде бандла (если ещё не появился), всё такие symfony2 ещё в бете.
Субъективно, 3 рhp-файла по 20 строк и 2 шаблона это не так уж и много кода для функционала блога. Единственное, чего нет в symfony2, так это admin generator'a из symfony1. C ним бы не пришлось создавать и эти файлы. Возможно, скоро и этот функционал появится в виде бандла (если ещё не появился), всё такие symfony2 ещё в бете.
Появился, уже давно.
Вот и дождались — symfony.com/blog/symfony2-getting-easier-interactive-generators
Относительно разработки без фреймворка — не много. Я же невольно оцениваю любой фреймворк, опираясь на опыт Рельс. Для примера, файл с моделью поста выглядел бы так:
Чувствуете разницу?
class Post < ActiveRecord:Base
belongs_to :user
end
Чувствуете разницу?
Не чувствую. Вы забыли про миграции. Получилось бы почти тоже самое.
Ой, да ради бога:
И это при том, что миграции гораздо более удобны и не захламляют основной код.
class CreatePosts < ActiveRecord::Migration
def self.change
create_table :posts do |t|
t.string :title
t.text :body
t.references :user
t.timestamps
end
end
end
И это при том, что миграции гораздо более удобны и не захламляют основной код.
/** @Entity */
class Post
{
/** @Id */
private $id;
/**
* @ManyToOne(targetEntity="User", inversedBy="posts")
* @JoinColumn(name="user_id", referencedColumnName="id")
*/
public $user;
/** @Column(name="title", type="string", length=255) */
public $title;
/** @Column(name="description", type="text") */
public $description;
}Намного ужаснее выглядит. Спор о фломастерах. И да, мне нравятся подход Рельс, да и рельсы тоже, просто это не повод забивать на все остальное.
Пишем приложение на symfony2 + doctrine2 (~2000 человекочасов уже). Symfony довольны, особенно community. А вот с Doctrine2 стоит быть осторожным — я за время использования нашел некоторые баги, один из которых вчера пофиксили в апстриме, а другой так до сих пор и висит в их JIRA, несмотря на то что там репорт+тест+патч
по обилию кода очень на кое кого смахивает
А тем временем вышла Symfony2 beta4. Впечатляет активность и прогресс разработки.
Чем именно? Активность последние 3 месяца, ребята конечно работают на износ, но обновляться каждую неделю (с правками сопутствующих багов) честно говоря уже достало )
Вот как раз тем как они работают. Извините, у меня просто нет приложений на Symfony2. Я пока слежу за разработкой.
Я до марта месяца следил, потом взялся делать небольшое приложение под Facebook. И сейчас для себя что-то типа такого блога делаю ) В документации поуши, постоянно меняется что-то, так что для активной разработки (во всяком случае коммерческой) не подходит. Хотя ребята делают проекты, с десятками моделей, самодельными админ-генераторами и т.п. )
Я наверное не попаду в струю, но эта жесть мне кажется куда менее клёвой и удобной, чем sf1.x. Наверное, пока нет рабочих генераторов sf2 так беспомощно выглядит. В общем, есть большая вероятность, что останусь на 1.4, которая куда как приятнее и логичнее для меня.
Попробовал делать сайт одновременно на симфони 2 и на симфони 1.
Симфони 2 очень хороший и мне безумно нравятся идеи в нем заложенные. Но сайт написал на симфони 1, который ругаю и не люблю. Почему? На симфони 1 быстрее в разы.
Симфони 2 я бы выбрал для большого проекта на много разработчиков, где важна не скорость индивидуальной разработки, а строгость исполнения.
Симфони 2 очень хороший и мне безумно нравятся идеи в нем заложенные. Но сайт написал на симфони 1, который ругаю и не люблю. Почему? На симфони 1 быстрее в разы.
Симфони 2 я бы выбрал для большого проекта на много разработчиков, где важна не скорость индивидуальной разработки, а строгость исполнения.
Ну как бы на 1.4 опыта больше. Потому и быстрее. Я столкнулся с аналогичной проблемой. Но с symfony2 ситуация как с теми мышами которые «плакали, кололись, но продолжали жрать кактус» )) Ибо идеи в нем заложенные мне тоже очень нравятся.
Я сплю и вижу как буду составлять проекты из блоков-бандлов одной левой )) и все сразу с тестами, и все суперклево ))) но это пока только во сне.
Я сплю и вижу как буду составлять проекты из блоков-бандлов одной левой )) и все сразу с тестами, и все суперклево ))) но это пока только во сне.
В попытке сделать фреймфорк аля django/ror на php symfony 1 однозначно потерпел фиаско. Оно и не удивительно, ведь даже сам синтаксис php никак не похож ни на ruby ни на phyton не говоря даже об объектном начале (против процедурного в php). Реализация в стиле ASP.NET MVC и Spring Framework кажется более удачным началом. Возможно, это даже приведет к тому, что symfony станет enterprise ready. Все зависит от коммьюнити.
Ох, как же оно этими конфигами и аннотациями похоже на Spring в Java. Монструозное очень.
Да только эта кухня вышли в preview релиз, уже было ясно что это Java. Насколько я знаю everzet один из активных коммитеров в symfony2. Костя, вам люди уже сказали что эта кухня никому не нужна в стартапах, потому что это (время на проект * 2) ради сомнительной выгоды… в частности сетеров и гетеров,… с каких пор php уже жабабинсами стал? Анатоции через комментарии, бл@zzz?
Да ну… по моему это академический фреймворк. А то что shopopensky.com делают себя на нем, не удивительно если J.Wage там работает
Да ну… по моему это академический фреймворк. А то что shopopensky.com делают себя на нем, не удивительно если J.Wage там работает
если писать на symfony2 то лучше уже сразу на java/scala перейти и это не преувеличение
Посещали такие мысли (насчёт Java, у Scala вроде функциональный подход, на который на практике у меня мозги не поворачиваются для CRUD и «бухгалтерских» приложений), но начал знакомиться с процессом деплоймента и что-то энтузиазм пропал — на симфони (как и на любом другом приложении на php) я могу написать в Install Guide, утрируя: «скачайте архив, разархивируйте, закачайте в корень сайта. Если у вас не виртхостинг, то предварительно сделайте apt-get install php5 mysql php5-mysql». Всё! Но вот хостингов на Java, на которые можно было бы просто залить исходники по ftp и сайт бы заработал я не встречал.
Можете забыть про обычные хостинги для sf2. Вам придется юзать VDS. А если уже такая кухня пошла то легче юзать django например, куча модулей уже готовых, кода в 3!!! раза меньше писать, и фреймворк намного! проще sf2, и быстрее :) Я могу сказать одно, что команда symfony сама себя в такое положение поставила. Делая из скриптового языка, и подхода в программировании, жалкое подобие компилируемой java.
И не сравнивайте мягкое с теплым. Вы сначала скорость сравните scala и php. Если есть куда дейплоить то загрузка тоже сводится до выгрузки .war файла и не надо никаких apt. Сервер приложений для java проектов и скриптовых движок косящий под него, это совсем разные вещи.
И не сравнивайте мягкое с теплым. Вы сначала скорость сравните scala и php. Если есть куда дейплоить то загрузка тоже сводится до выгрузки .war файла и не надо никаких apt. Сервер приложений для java проектов и скриптовых движок косящий под него, это совсем разные вещи.
Про обычные хостинги для себя я давно забыл. Но вот с той же Django не согласен, про RoR вообще молчу. Писать может и меньше, но у меня скорость разработки редко ограничена скоростью набора кода и тестов для него — думать больше приходится.
Да и развертывание приложений на голом (v)ds под (или над?) ними, имхо, требует развитых навыков администрирования в отличии от php. Вы правильно сказали — «если есть куда деплоить», имхо настроить сервер приложений на порядки сложнее, чем поднять LAMP. А скорость адекватно сравнить не могу — в ФП я лишь немногим больше, чем ноль и мой код будет императивным, запихнутым в рамки функционального подхода, то есть органично сочетающий их недостатки. И вы действительно считате, что блог или сайт-визитку лучше делать на Scala или Java, чем на PHP, Python или Ruby?
Да и развертывание приложений на голом (v)ds под (или над?) ними, имхо, требует развитых навыков администрирования в отличии от php. Вы правильно сказали — «если есть куда деплоить», имхо настроить сервер приложений на порядки сложнее, чем поднять LAMP. А скорость адекватно сравнить не могу — в ФП я лишь немногим больше, чем ноль и мой код будет императивным, запихнутым в рамки функционального подхода, то есть органично сочетающий их недостатки. И вы действительно считате, что блог или сайт-визитку лучше делать на Scala или Java, чем на PHP, Python или Ruby?
Во-первых в scala можно писать без ФП, или по крайней мере использовать его по минимуму, там ничего сложного нет, не сложнее ruby. Там есть намного сложнее вещи, система типов и т.д. Ну неважно.
Ну я не знаю если для вас сложно разобраться с методами дейплоймента или настройки ну тогда стоит специалиста нанять. Просто вы сравнили установить интерпретатор и установить и настроить сервер приложений. Это как бы завести мопед или перебрать двигатель в нем и завести. Ну это совсем разные задачи. Есть куча хостингов Java, но хороший найти чуть сложнее чем хороший с php найти. Именно чуть.
Я не о сайте визитке говорил(читайте выше) а вообще о фреймворке. Визитку, блог, проще написать на django, чем на symfony. Объясняю почему. К слову, я с sf1 2 года проработал. Так вот, то что вы больше думаете когда пишите это замечательно, но как насчет последующей поддержки? В 3-5!!! раза больше кода получается в вашем приложении по сравнении с django приложением. Код намного больше запутан. Соответсвенно менять что-то дольше, так как вы в реальной жизни не сможете обойтись красивыми чистыми классами как doctrine2 навязывает. Это раз. Теперь взлянем на ситуацию новый программист хочет/нужен прийти в проект но незнает sf2, вы представляете сколько нужно времени чтобы он въехал в этот фреймворк и тогда уже в проект. Вы посчитайте сколько там технологий, если их выучить то это проще 60% технолигий выучить для java веб разработки, и получать 2-3 раза больше денег. Это два. И это ответ почему коммюнити не будет расти как будто какая то революция произошла. А я прекрасно помню как sf2 заявлялся года 1.5 назад. И три. Сравните бенчмарки через apache benchmark например 200 одновременных запросов c общей суммой запросов 10к например. Обычный не очень нагруженный сайт, к которому в один момен может стукнуться 200 пользователей а потом сразу еще 200. И тоже самое с тем же django. И вы увидите что у вас выхода не будет кроме как наставить все кешировать. Varnish и писать для приложения кеши. И это только с самого начала жизни сайта, а что будет потом? Мне такой фреймворк не нужен, придеться только им и заниматься как бы что не просело.
Ну я не знаю если для вас сложно разобраться с методами дейплоймента или настройки ну тогда стоит специалиста нанять. Просто вы сравнили установить интерпретатор и установить и настроить сервер приложений. Это как бы завести мопед или перебрать двигатель в нем и завести. Ну это совсем разные задачи. Есть куча хостингов Java, но хороший найти чуть сложнее чем хороший с php найти. Именно чуть.
Я не о сайте визитке говорил(читайте выше) а вообще о фреймворке. Визитку, блог, проще написать на django, чем на symfony. Объясняю почему. К слову, я с sf1 2 года проработал. Так вот, то что вы больше думаете когда пишите это замечательно, но как насчет последующей поддержки? В 3-5!!! раза больше кода получается в вашем приложении по сравнении с django приложением. Код намного больше запутан. Соответсвенно менять что-то дольше, так как вы в реальной жизни не сможете обойтись красивыми чистыми классами как doctrine2 навязывает. Это раз. Теперь взлянем на ситуацию новый программист хочет/нужен прийти в проект но незнает sf2, вы представляете сколько нужно времени чтобы он въехал в этот фреймворк и тогда уже в проект. Вы посчитайте сколько там технологий, если их выучить то это проще 60% технолигий выучить для java веб разработки, и получать 2-3 раза больше денег. Это два. И это ответ почему коммюнити не будет расти как будто какая то революция произошла. А я прекрасно помню как sf2 заявлялся года 1.5 назад. И три. Сравните бенчмарки через apache benchmark например 200 одновременных запросов c общей суммой запросов 10к например. Обычный не очень нагруженный сайт, к которому в один момен может стукнуться 200 пользователей а потом сразу еще 200. И тоже самое с тем же django. И вы увидите что у вас выхода не будет кроме как наставить все кешировать. Varnish и писать для приложения кеши. И это только с самого начала жизни сайта, а что будет потом? Мне такой фреймворк не нужен, придеться только им и заниматься как бы что не просело.
>>> Соответсвенно менять что-то дольше, так как вы в реальной жизни не сможете обойтись красивыми чистыми классами как doctrine2 навязывает.
А если и сможете все аккуратно делать, то вы будете писать столько сколько пишутся java приложения, по несколько месяцев. Вот теперь скажите кто будет платить за эту сомнительную выгоду? А поскольку sf dev как человек знающий не мало захочет неплохой рейт в час, то как вы думаете кого будет предпочтительнее нанять заказчику разработчика python который пишет быстро! на django или sf2 дэва который не может объяснить почему его проект стоит так же как на django а может и дороже и ему еще нужно больше времени. Вот и все. Тут решит все рынок.
А если и сможете все аккуратно делать, то вы будете писать столько сколько пишутся java приложения, по несколько месяцев. Вот теперь скажите кто будет платить за эту сомнительную выгоду? А поскольку sf dev как человек знающий не мало захочет неплохой рейт в час, то как вы думаете кого будет предпочтительнее нанять заказчику разработчика python который пишет быстро! на django или sf2 дэва который не может объяснить почему его проект стоит так же как на django а может и дороже и ему еще нужно больше времени. Вот и все. Тут решит все рынок.
Я так понял, ему важнее защитить свою точку зрения, а не услышать других.
имхо, он не сможет повлиять никак, я на symfony v1.x уже около 2.5 лет проработал, я вынес один урок, что sensio ни к кому не прислушивается, даже если это конструктивная критика… поэтому я для себя решил что с смертью sf1 перейду на django… а это в 3 раза меньше кода писать чем в sf2
конечно я сгораю от любопытства увидеть большой открытый проект на sf2, но имхо 80% даю что это epic fail…
он просто настолько сложный будет, что на нем смогут писать только те кто знают более менее 2-3 ЯПа
для программиста с 1 годом стажа он будет недосягаем
конечно я сгораю от любопытства увидеть большой открытый проект на sf2, но имхо 80% даю что это epic fail…
он просто настолько сложный будет, что на нем смогут писать только те кто знают более менее 2-3 ЯПа
для программиста с 1 годом стажа он будет недосягаем
Я бы не драматизировал. Чувствую, они всё это понимают, но в первую очередь симфони и доктрина это метафреймворки, на них можно создавать удобные штуки, главное, пока избавить проекты от тех ограничений, что были в sf1. Удобство можно будет добавить потом. Нету никаких объективных причин почему нельзя спрятать мощь симфони за простой оберткой. Просто пока об этом никто не думает, или это не афишируется. Но пример Silex, FrameworkExtraBundle и Doctrator говорит о том, что впринципе такое будет создаваться и будет поощряться.
«что на нем смогут писать только те кто знают более менее 2-3 ЯПа для программиста с 1 годом стажа он будет недосягаем»
Хе-хе. а в рельсах 3.1 добавили 2 новых языка программирования, и тем не менее они стали удобнее ) Всё-таки они развиваются как-то лучше, без революций, но именно целясь на удобство разработчиков. В Rails 3 они перелопатили всю архитектуру ActiveRecord, но переход достаточно несложным оказался. В симфони всё не так :(
Хе-хе. а в рельсах 3.1 добавили 2 новых языка программирования, и тем не менее они стали удобнее ) Всё-таки они развиваются как-то лучше, без революций, но именно целясь на удобство разработчиков. В Rails 3 они перелопатили всю архитектуру ActiveRecord, но переход достаточно несложным оказался. В симфони всё не так :(
Не понимаю почему так все набросились на Symfony2.
Мне он очень даже понравился. Своей гибкостью.
Это только сначала все кажется трудным и запутанным.
Когда приходит понимание — все делается довольно быстро.
Не вижу причин не использовать его для стартапов.
Мне он очень даже понравился. Своей гибкостью.
Это только сначала все кажется трудным и запутанным.
Когда приходит понимание — все делается довольно быстро.
Не вижу причин не использовать его для стартапов.
Попробовал сделать все, как в примерах… Произошел затык на этапе создания таблиц, выдает ошибку:
буду благодарен за помощь. Сам я раньще вообще не связывался с фреимворками, решил попробовать поработать с Symfony 2. Пока темный лес…
[Symfony\Component\Config\Definition\Exception\InvalidTypeException]
Invalid type for path "security.firewalls.pattern". Expected array, but got string буду благодарен за помощь. Сам я раньще вообще не связывался с фреимворками, решил попробовать поработать с Symfony 2. Пока темный лес…
Скажите, а зачем в «В app/config/config.yml удаляем auto_mapping»
Я сам только что перешёл с первых версий Symfony и Doctrine на вторые и ещё не до конца разобрался, как работает mapping, но, насколько я понял, во-первых, и с auto_mapping всё работает, а во-вторых, если его убрать, придётся всё время помнить, что надо прописать маппинги при добавлении новых бандлов.
Или я не прав?
Я сам только что перешёл с первых версий Symfony и Doctrine на вторые и ещё не до конца разобрался, как работает mapping, но, насколько я понял, во-первых, и с auto_mapping всё работает, а во-вторых, если его убрать, придётся всё время помнить, что надо прописать маппинги при добавлении новых бандлов.
Или я не прав?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Простейший блог на Symfony 2