лол. вы серьезно?
напишите хотя бы почему вы в эту цепочку добавили Jenkins. И почему именно Postgresql? с мускулем работать не будет?
деплой это тот ещё гемор. Даже с капистранкой. Но когда есть опыт и написанные рецепты деплоить всяко проще и горадо проще чем на PHP.
JavaScript создан чтобы показывать менюшки и попапы
SQL создан чтобы писать сайты визитки
Ruby создан чтобы был конфы для хипстеров куда они могли бы таскать свои макбуки
Python создан чтобы не учить Perl
Java создана чтобы тормозить
C# создан чтобы не учить C++
Haskel создан чтобы потролить
Scala создана чтобы трудоустроить тех кто выучил хаскель.
Lisp создан чтобы все научились закрывать скобочки
Prolog создан чтобы было что в универе преподавать
Visual Basic создан, но не надо.
ObjectiveC создан чтобы хипстеры могли выучить кроме руби ещё что-то.
Dart создан, чтобы быть закрытым в 2018 году вместе с прекращенеим официальной поддержки от гугла.
Чтобы оно действительно напоминало рельсы, было бы неплохо иметь метод change вместо up и down
Писать постоянно миграции в обе стороны крайне напряжно. Особенно с учетом того, что очень мала веротяность что миграции вниз реально понадоятся.
Думаю автор специально подменял суть формой, лишь бы набить символы, за которые ему платят. Но честно, если ему заплатили годичное жалование за «это», то это грустно. Да и текст, скорее наотмашку. побольше сантиментов, побольше родственников, семьи, теплых ламповых бумажных писем… О чем всё это?
Что я понял из статьи — у чувака нет друзей. Какую социальную жизнь он вообще хотел вести?
Впрочем, тут нет какой-то прямой взаимосвязи.
Компоненты Симфони никак не связаны с оверхедом фреймворка Symfony2: конфигурацией, бандлами, DIC и прочими фишками. Сами компоненты легковесны и приятны. Используются также в Laravel, Silex, Drupal.
Проблема тут только в том, что идиоты могут юзать эту переменную там где это вообще не нужно. Например, во вьюшках вызывать экшны или делать прочую муть. То есть нужно как-то контролировать доступ к этому свойству (а также к БД).
Почему же, она решает эти вещи… Ок, события они хороши сами по себе. Их, допстим, трогать не будем :)
Но для behavior — самое оно.
При __call, мы уже не будем в рантайме перебирать все доступные behaviors и не будем искать в них методы, а уже будем обладать готовым списокм доступных методов, которые будут проксироваться в behvaiors.
Ах да, плюсом прекомпиляции как по мне может быть то, что она работает с существующим решением. Допустим, если класс не сблиджен идет фолбек к магическим методам и свойствам.
А можно узнать оставите ли вы такую же реализацию компонентов или будет что-то новое.
Просто вся эта реализация через magic методы get/set она крайне хрупкая и да, попахивает черной магией.
Что можете сказать по поводу альтернатив:
* трейты ( уже ж 5.5 почти вышел, пора смело переходить на 5.4)
* прекомпиляция — генерация файла со всеми внутренними свойстами и методами.
Имхо любое из этих решений будет удобнее. Плюсы:
* можно получить чистый стектрейс
* можно всегда перейти к нужному методу
* всегда есть понимание чье это свойство и чей это метод.
* решение ситуаций вызова несуществующих свойств-методов ещё на этапе препроцессинга.
Кстати я про себя отметил, что многие разработчики презрительно смотрят на кофискрипт и да, не используют его из идеологических или других мотивов. Просто в какой-то момент всё равно придется лезть в код библиотеки и там бы хотелось видеть более знакомый язык.
Лично я люблю кофискрипт и код в нем мне кажется проще и понятнее.
Ну потому так много фреймворков, чтобы вы могли выбрать для себя то что надо по вкусу.
Тут могу сказать, что подход эмбера в этом плане лучше. С одной стороны, у них двонаправленная связь (что несомненно удобно при разработке приложений — вьюхи меняются при изменении модели). С другой это релаизовано без дата-атрибутов, а в рамках шаблонизации.
Тут соглашусь. Тоже долго дебажил из-за того, что скобки зафтыкал проставить (а кофискрипт в этом плане расслабляет). И тоже никакого внятного меседжа :(
Я думаю проблема всех этих обзоров — не четко описаны юз кейсы. Хотелось бы услышать что-то в стиле: здесь лучше применить marionette, тут backbone, тут можно ангуляром и т.д.
Хм, странно чего не завелся. У меня все проблемы были только из-за того, что я пытался всё нахрапом в кофискрипт перевести. Кстати, у ембера есть свой кофискриптс блекджеком и шлюхами. В ембере нужно юзать только последнюю версию. Ну и создать инстанс приложения, роута и моделек. За вечер разобрался… Вроде как… Типа того…
Возможно стоит добавить какие-то критерии по работе с кодом фреймворка.
Допустим, Backbone и Ember очень похожи в том плане как они работают с классами, как определяют атрибуты, функции, биндинги.
А вот у Ангуляра совершенно свой путь, который я так и не смог понять: скоупы, ресурсы, Depenency Injection… Намного привычнее работать со стандартными View-Model-Router.
Ещё бы посоветовал взглянуть на BatmanJS. Он как мне кажется вобрал лучшее от Ангуляра и Эмбера. С одной стороны Convention over configuration, привычные Model, View, Controller, простота использования и низкий порог вхождения. С другой, он пока слабо документирован и малочисленное сообщество. Но работа с определенно фреймворком радует.
Лично скажу по себе, то стоит задуматься а стоит ли? Symfony1 и Symfony2 не более чем один и тот же бренд и те же разработчики.
Но идеология всего фреймворка Symfony2 совсем иная. Это уже скорее Spring.
Стоит ли менять идеологию веб-разработки — решать вам. Но к симфони1 намного ближе тот же Laravel (основан кстати на симфони компонентах), ну и тем более ближе Rails. Всё конечно зависит от целей и задач, но не делайте из изучения нового языка огромную преграду. Используйте то что удобно и эффективно, а не то что популярно.
напишите хотя бы почему вы в эту цепочку добавили Jenkins. И почему именно Postgresql? с мускулем работать не будет?
деплой это тот ещё гемор. Даже с капистранкой. Но когда есть опыт и написанные рецепты деплоить всяко проще и горадо проще чем на PHP.
JavaScript создан чтобы показывать менюшки и попапы
SQL создан чтобы писать сайты визитки
Ruby создан чтобы был конфы для хипстеров куда они могли бы таскать свои макбуки
Python создан чтобы не учить Perl
Java создана чтобы тормозить
C# создан чтобы не учить C++
Haskel создан чтобы потролить
Scala создана чтобы трудоустроить тех кто выучил хаскель.
Lisp создан чтобы все научились закрывать скобочки
Prolog создан чтобы было что в универе преподавать
Visual Basic создан, но не надо.
ObjectiveC создан чтобы хипстеры могли выучить кроме руби ещё что-то.
Dart создан, чтобы быть закрытым в 2018 году вместе с прекращенеим официальной поддержки от гугла.
Писать постоянно миграции в обе стороны крайне напряжно. Особенно с учетом того, что очень мала веротяность что миграции вниз реально понадоятся.
Что я понял из статьи — у чувака нет друзей. Какую социальную жизнь он вообще хотел вести?
Впрочем, тут нет какой-то прямой взаимосвязи.
Компоненты Симфони никак не связаны с оверхедом фреймворка Symfony2: конфигурацией, бандлами, DIC и прочими фишками. Сами компоненты легковесны и приятны. Используются также в Laravel, Silex, Drupal.
Но для behavior — самое оно.
При __call, мы уже не будем в рантайме перебирать все доступные behaviors и не будем искать в них методы, а уже будем обладать готовым списокм доступных методов, которые будут проксироваться в behvaiors.
Ах да, плюсом прекомпиляции как по мне может быть то, что она работает с существующим решением. Допустим, если класс не сблиджен идет фолбек к магическим методам и свойствам.
Просто вся эта реализация через magic методы get/set она крайне хрупкая и да, попахивает черной магией.
Что можете сказать по поводу альтернатив:
* трейты ( уже ж 5.5 почти вышел, пора смело переходить на 5.4)
* прекомпиляция — генерация файла со всеми внутренними свойстами и методами.
Имхо любое из этих решений будет удобнее. Плюсы:
* можно получить чистый стектрейс
* можно всегда перейти к нужному методу
* всегда есть понимание чье это свойство и чей это метод.
* решение ситуаций вызова несуществующих свойств-методов ещё на этапе препроцессинга.
Лично я люблю кофискрипт и код в нем мне кажется проще и понятнее.
Тут могу сказать, что подход эмбера в этом плане лучше. С одной стороны, у них двонаправленная связь (что несомненно удобно при разработке приложений — вьюхи меняются при изменении модели). С другой это релаизовано без дата-атрибутов, а в рамках шаблонизации.
(шутка понятная симфонистам)
с блекджеком и шлюхами. В ембере нужно юзать только последнюю версию. Ну и создать инстанс приложения, роута и моделек. За вечер разобрался… Вроде как… Типа того…blog.susestudio.com/2013/03/client-side-js-mv-framework-roundup.html
Внезапно там тоже рекомендуют Ватмана )
Допустим, Backbone и Ember очень похожи в том плане как они работают с классами, как определяют атрибуты, функции, биндинги.
А вот у Ангуляра совершенно свой путь, который я так и не смог понять: скоупы, ресурсы, Depenency Injection… Намного привычнее работать со стандартными View-Model-Router.
Ещё бы посоветовал взглянуть на BatmanJS. Он как мне кажется вобрал лучшее от Ангуляра и Эмбера. С одной стороны Convention over configuration, привычные Model, View, Controller, простота использования и низкий порог вхождения. С другой, он пока слабо документирован и малочисленное сообщество. Но работа с определенно фреймворком радует.
Но идеология всего фреймворка Symfony2 совсем иная. Это уже скорее Spring.
Стоит ли менять идеологию веб-разработки — решать вам. Но к симфони1 намного ближе тот же Laravel (основан кстати на симфони компонентах), ну и тем более ближе Rails. Всё конечно зависит от целей и задач, но не делайте из изучения нового языка огромную преграду. Используйте то что удобно и эффективно, а не то что популярно.