It-компот 32 (продолжение)

Начало
antonkopylov – То есть ты сейчас в сторону копаешь?

netandreus – Я копаю в сторону модулей, я сейчас думаю, что мне выбрать или банлы Symfony либо модули ZF2. И я этот вопрос исследую. Автозагрузку я уже исследовал, там все замечательно грузится в ZF2, великолепно.

hackPNZ – А, кстати в Symfony второй версии у них там можно взять один компонент того же DI, например, и поюзать, можно взять еще какой-то компонент, я уже не помню… Что в этом плане у ZF2? Потому что первый ZF он все-таки в этом плане был связанный, что касается базовой его структуры и так далее. Здесь можно как-то брать небольшие его модули только для routing’а, например, и использовать это в своем проекте, не беря дополнительных, более тяжелых вещей?

netandreus – По идее, да. Там есть некое количество компонентов, их можно использовать отдельно. Когда я в первый раз познакомился с ZF, в чем для меня открылась его философия? У нас есть компоненты, мы можем их использовать отдельно, и нас никто не заставляет их использовать вместе, но ты используешь один компонент, используешь второй компонент, третий, и потом ты понимаешь, что вместе их использовать удобнее. И вот именно вот это «удобнее», оно потом и стимулирует тебя к использованию всего framework’а. Можно использовать. В первом без application можно обойтись, без bootstrap, это будет быстрее.

hackPNZ –А, кстати, Антон, хотел у тебя спросить, у вас в Рельсах на Ruby есть какие-то такие похожие задачи и проблемы при переходе или при использовании каких-то ваших компонентов, гемов?

antonkopylov – Ну, да. Я понял вопрос. Смотри, вот Рельсы в последнее время, наверное, год или больше, идут в сторону модульности, чтобы можно было более гибко какие-то элементы убирать или подключать. То есть Рельсы версии 1 или 2 были такой вот монолитной здоровой системой, а вот начиная с третьей и четвертой, которая скоро выйдет, там все очень гибко, там по отдельности можно все включать, выключать. Ты можешь там, допустим, то, что active record с моделями связанное, подключать вообще отдельно, использовать без Рельсов в отдельном своем проекте, в свои классы прямо. Вот функциональность валидации или еще что-то такое – подключил отдельный классик, и оно работает.

hackPNZ – Active record это вообще у вас крутая штука, и многие прямо вот пытались их содрать в PHP и framework в том числе, по-моему.

antonkopylov – Ну, понимаешь, тут не получается, потому что сам язык Ruby даёт метаинформацию, метапрограммирования, удобно очень дает, и в PHP такого нет, и так удобно не сделаешь, как там, как в Ruby. В плане модульности, Рельсы идут в сторону модулей, и они, кстати, знаешь еще чем мне нравятся? Они не боятся выкидывать старье deprecation, они нещадно вырезают все то, что считают устарелым, поэтому, ребята, выкидывайте, что хотите, адаптируйте все ваши приложения, переходите на новые какие-то вещи. Все, что считают лишним, выносят в отдельные геммы. Все, если считаю разработчики, что большинству людей это не надо, мы выносим это в отдельный гемм, кому надо, он будет себе подключать, обратно эту функциональность подключать. То есть в этом плане Рельсы очень динамичная система, и всегда в любом проекте, который ты начинаешь, тебе приходится через некоторое время его переписывать еще до того, как ты успел его дописать, потому что скорость изменения самой платформы быстрее, чем ты пишешь приложение.

hackPNZ – Получается, то, что мы сейчас обсуждаем в плане Zend Framework, оно пересекается как-то и с Рельсами. То есть, я так понимаю, что путь какой-то примерно такой же будет, да?

antonkopylov – Видишь, здесь как бы один, два. Один раз такой глобальный переход возник, а в Рельсах я много раз глобально изменений выносил, приходилось вносить, потому что оно там постоянно происходит.

hackPNZ – Понятно. То есть мы сейчас идем в сторону того, что по частям, помодульно внедрять, и тот путь, когда мы отдельно берем и параллельно два проекта разрабатываем, скорее всего, мы на нем не остановимся. Мы все-таки как-то вместе наши framework’и совмещать и как-то по модулям их пытаться переписать.

antonkopylov – Не знаю, насчет совмещать. Конечно, сложный вопрос…

hackPNZ – Cложный.

antonkopylov – Тут нет какого-то решения волшебного, если большие изменения, т о никуда не денешься, придется переписывать.

hackPNZ – Понятно. Кстати, хотел спросить у Андрея и у Георгия. У меня тоже есть проект, но я его не полностью не собираюсь переводить с ZF1 на ZF2, потому что я использую больше компоненты какие-то от ZF – сервисы http-клиент, что-то такое вспомогательное, Zend_Json , Zend_Mail, Zend_Service_Amazon, например. Есть ли смысл в переводе? Стали ли эти сервисные компоненты в ZF2 более удобными, либо они просто большинство как есть, так и перекочевали во второй framework? Есть ли смысл здесь переходить в таком проекте на ZF2?

netandreus – Я сильно сомневаюсь, что они стали чем-то лучше, они и так были достаточно хороши. Фраза была на конференции: «Первый framework был хорош, а этот еще лучше». А что касается компонентов, то там все завязано на API и реализации взаимодействия с этим API. Я думаю, нет, нет смысла, если у тебя только какой-то Zend сервис Amazon, переходить на второй framework. Потому что профита особого ты не получишь, единственное, namespace’ы, если у тебя весь проект на namespace’ах, а тут вдруг у тебя часть первого ZF что касается сервиса, тогда можно. Чтобы все было PSR-0? Лучше, конечно, когда весь проект в PSR-0. А так я не вижу смысла. Если конкретнее, то надо читать backtrack, changelist и смотреть, что вообще произошло с Zend service что-то там..

hackPNZ – Ясно.

zhorzh – Я бы хотел здесь добавить, вот последнее предложение Андрея было самым рациональным. Тебе нужно посмотреть конкретно по конкретным компонентам уже, что было изменено, потому что изменения, действительно, в сторону улучшения были. Даже слышал изменения от того же Виктора Фараздаги, одного из наших ZF2 контрибуторов, он специально перепиливал под PHP 5.3, под какие-то новые features, как-то рефактурил, новый дизайн применял для компонентов, я точно не помню, какие именно это были компоненты; но вообще он сделал немало improvement’а после того, как компоненты просто так были переведены на namespace’ы. Он еще начал потом активно их перепиливать. Поэтому имеет смысл все-таки для каждого отдельного компонента, который ты используешь, уже конкретно рассматривать ситуацию, будет ли тебе профит или нет.

antonkopylov — Да, потому что и в дальнейшем можно эти компоненты с новыми версиями второго ZF забирать. Здесь, наверное, зависит от того, действительно, требуется ли что-то тебе конкретно и будет ли удобство, потому что, если проект хорошо живет с первым ZF, и в принципе, тут важнее какая-то стабильность, что у тебя все работает, и тебя это устраивает, и больше сервисы ты вряд ли будешь юзать. Тогда, наверное, смысла нет, мне кажется, лишнее время тратить и метаться. А если есть смысл, возможно, что-то будет постоянно пригождаться, еще какие-то сервисы, еще какой-то функционал существующих используемых сервисов, тогда может быть. Я пока еще не определился, уж больно он у нас пока выборочно используется, просто пытался понять, стоит ли вообще. Наверное, посмотрю и исследую этот вопрос для себя и что-то решу, то есть насколько это вообще нужно.

zhorzh – Андрей, слушай, по поводу миграции, мне хотелось бы больше углубится в конкретные технические детали, поскольку я сам не сильно инвестигировал ZF 2, вот уже конечную реализацию. Вот если прямо, конкретно идти по ZF 1 компонентам. Есть вот у нас action controller, и у него есть отдельные action’ы, в ZF2 это что будет? Мне нужно код одного action’а перевести из ZF1 в ZF2, как это все делается?

netandreus – Тут все сильно зависит от того, что же в этом action’е. Вообще, по идее, в экшене ничего не должно поменяться. То есть у тебя есть старый код, ты его переносишь в новый ZF, а потом смотришь, что отвалилось.

zhorzh – Ну, да в новом ZF там что тоже action controller’ы есть? Или там можно к какому-то событию привязываться?

hackPNZ – Нет, там есть action controller’ы. Просто представь, то, что было в action controller postDipatch, preDispatch – вот они вынесены в события. Вот много у вас в проекте таких частей, которые завязаны на эти, скажем до диспетчеризации action’а и после него? Вот таких вообще много или все в action сидит?

zhorzh – Ты имеешь в виду preDispatch и postDispatch именно которые именно в action controller’ах вызывались?

hackPNZ – Да.

zhorzh – Нет, таких мы вообще не используем, у нас используются для этого action helper’ы и plug in controller’ы.

netandreus – Вот их вам и придется переписать.

zhorzh – То есть action controller’ы мне нужно, грубо говоря, перекинуть на name spaces, и он у меня заработает сразу?

netandreus – Первый шаг – да, ты перекидываешь его в name space, делаешь свой модуль, кидаешь контроллеры и запускаешь, смотришь, что работает, что не работает. А сервисный слой у вас, наверняка, есть какой-то.

zhorzh – Нет, сервисного слоя у нас нет, собственно контроллеры это и есть сервисный слой.

netandreus – Тогда вам проще будет.

hackPNZ – То есть получается, толстые контроллеры такие, там много логики в самом контроллере реализовано так?

zhorzh – Тут сложно сказать. Тут я, наверное, немножко слукавил. Там есть проблема в этом проекте, что за сервисный слой отвечает модель, то есть некоторые сервисные штуки перенесены в модель. Контроллеры на самом деле в большинстве своем достаточно тонкие – это либо сохранение формы, проверка валидирования и передача в модель. Но есть и толстенькие контроллеры тоже.

antonkopylov – Ну, это мне тоже знакомо, у нас тоже раньше такое было. Вместо сервисного слоя до того, как мы все переписали сейчас на MongoDB, у нас все было на ZF, собственно, так оно все и работало. Толстые модели, там была куча каких-то методов, и сейчас мы от этого ушли. Тут тоже есть проблемы с service layer, я уже это обсуждал, это тема отдельная и сейчас нет смыла это затрагивать излишне. Тема богатая, там можно не один, и не два, и не три выпуска на этот счет записать, и все равно еще останется, о чем поговорить, и что не обсудили.

netandreus – Да, тут тоже почва для холиваров. Некоторые говорят, зачем сервисный слой, у нас толстый контроллер, и там будет все отлично, тоненькая модель будет, а все в контроллеры. Другие, наоборот, любят толстые модели, то есть не использовать сервисный слой. А мне кажется, что просто надо его использовать и все. А там уж какой он будет, как он будет, главное, чтобы он был, чтобы он не лез в модель или в контроллер.

antonkopylov – Ну, у нас и получается совмещать вызовы одних и тех же сервисных методов, то есть делать без проблем вызовы и получать данные одинаково, скажем для клиентского API и для WEB. Для web по front end нам нужно то же самое делать, те же самые данные дергать из базы, поэтому мы однозначно сразу решили, что мы не можем завязываться на толстые контроллеры. Нужна какая-то абстракция, откуда мы будем данные вынимать, причем желательно, чтобы это была вещь в себе, чтобы там все внутри было. Чтобы уровень работы с базой, с Mongo или не с Mongo, чтобы он был скрыт в сервисах, чтобы мы просто получали данные там, где это нужно, и все, и дальше с ними как-то уже работали. У нас такой вот путь.

zhorzh – Тут видишь, действительно, вопрос очень широкий, и тут надо определяться, потому что то, о чем ты сейчас говоришь, по моему мнению, это не сервис, это модель. Поэтому я предлагаю вернуться к миграции.

hackPNZ – Да, чуть-чуть отвлеклись!

netandreus – Кстати, на конфе был доклад про это, вот эта вся тема была в докладе «Модель Management System», или MMS, посмотрите, почитайте потом.

antonkopylov – Андрей, можно еще такой вопрос. Вот я помню, когда сл вторых на третьи Рельсы мы переходили, это было примерно год назад, было очень много всяких tools’овин для автоматизации этого переноса проекта, которые проверяли — а вот здесь вам надо поправить, здесь вот то, се надо сделать.. . Есть какие-то средства для облегчения перехода, чтобы не все вручную делалось?

netandreus – Да, в Рельсах это, конечно, сказочная вещь, такая штука похожая в Symfony есть, какой-то Symfony Check, а в ZF я этого не видел. Может быть, оно есть, но я что-то о нем ничего не слышал.

zhorzh – Я знаю два tools’а для перевода на Name Space, чтобы перевести классы со старого наименования но новое . Но это была tools’а, заточенная под сам Zend Framework, я думаю, если ее поднять, то можно заточить ее и под сам проект. Вообще тема актуальная, вот Антон спросил, и ее нужно исследовать тоже, я думаю, все-таки есть какие-то tools’ы, даже если не в самом ZF, то кто-то из филированных ?? 58.07 людей что-то подобное должен написать, а если не должен, то это наша задача.

hackPNZ – Может, что-то посмотреть в сторону компонентов Zend_Tool, которые у них были. Ведь во втором ZF их развивали, насколько я помню, там все стало более функционально, более интересно, может, при помощи этих tool’ов по быстрому себе структурку создать и так далее.

netandreus – Tool’ы-то они могут, да, там в плане скафолдинга они продвинулись, но это же немножко разные вещи. Одно дело мы берем новый проект, скажем, новую ветку, делаем Zend tool’ом все наши штуки. Доктрины, генерим модели, условно говоря, тоже там через консоль, но все равно, я бы не сказал, что это перевод. Просто мы себе быстренько делаем новую похожую структуру.

hackPNZ – Да, мы подготавливаем новую чистенькую структуру для перевода, это понятно.

netandreus – Это и есть, да там скафолдинг лучше стал, там можно, как в Рельсах, делать контроллер с ation’ом, я не пробовал, я просто слышал, что есть такое, и сильно этому обрадовался.

hackPNZ – Ясно, я думаю, что нас будет слушать и ZF Community, и поэтому можно сделать такое небольшое воззвание, что в принципе, было бы круто такую tools’у сделать, написать и выложить в свободный доступ.

antonkopylov – Ну, а если кто знает, что она есть, пусть в комментах ссылочку мне даст, думаю, будет всем полезно.

hackPNZ — Да, чтобы была уже какая-то польза, какие-то правильные инструменты для миграции, потому что community очень активные, насколько я знаю, и очень хорошие. Много и наших ребят из России, и со стран СНГ, из Украины особенно, много чего сделали хорошего для Zend Framework, я думаю, здесь такой проблемы особенно не должно возникать. Это будет большим полюсом и для framework, и многие, возможно, примут решение, что им будет проще мигрировать, и они будут уже более конкретно задумываться, а не перейти ли нам на новый framework, выгоды у него свои появятся – он быстрее, лучше, гибче. Это будет здорово и круто, поэтому всячески могу только воззвать.

zhorzh – Возвращаясь к миграции, я хотел вот так кратенько… вот action контроллеры мы перекинули, там у нас еще был слой view, каким образом ZF1 он view подцеплялся там автоматически, ZF 2 там что-то поменялось или механизм тот же самый?

netandreus – Георгий, там есть одна большая засада, насколько я знаю, я ее сам не пробовал, но я о ней слышал от товарища. К переменным внутри виды мы раньше обращались This — название переменной. Во втором ZF они все как-то отображаются на Name Space, и мы их юзаем просто Название переменной. WAR и все, не This WAR, а просто WAR. То есть виды придется в этом плане переписать, и layout’ы, как следствие. Информация такая неподтвержденная, надо проверить.

zhorzh – Да, такой подарочек… В принципе, если это действительно так, то это тоже автоматизируемо — погрепать там, поскипать 01.01.38 автоматически этот This.будет у нас без This. Да, на самом деле, актуальный вопрос. А с view helper’ами там что? Там будет тоже без This? Как-то Name Space’ом подцепляться? Как мы можем в шаблоне подцепить Name Space? Как-то он не очень будет смотреться, мне кажется…

netandreus – Слушай, не скажу, про view helper’ы. Надо Skeleton-класс поднимать и смотреть, как там называется view helper.

hackPNZ – Кстати, хорошо, что есть такое тестовое приложение, как Skeleton, что можно легко поднять и быстро посмотреть. Скажем, у тебя возник какой-то конкретный вопрос: «А смогу ли я сделать так-то в ZF2?» ты, как Андрей, этим работал, ты какие-то вещи для себя быстренько смотрел?

netandreus — Конечно. Он для этого и создан, чтобы какие-то базовые вопросы отработать, как вот они там реализуются. Взять и посмотреть, где у нас вьюхи, как у нас называется.

hackPNZ – Да, я просто помню, что для первого ZF такой классной штуки не было.

netandreus – Нет, они были, но их было два. Один делал товарищ Akrabat, который… а второй делал еще кто-то. И причем они их, как бы, не особо поддерживали, что было плохо. То есть смотришь, так оно работает, делаешь так, а оно не работает. Думаешь, что такое, а они там чуть-чуть устарели. Но в comment’ах это все, в принципе, быстро находится. Да, вот, Джордж, по поводу твоего вопроса через This вызываются helper’ы. Открыл я Skeleton класс, они вызываются через This.

zhorzh — А я тоже как раз индекс-контроллер посмотрел.

netandreus – В translate там.

zhorzh – Локальные переменные…

netandreus – Да, переменных там почему-то нету, вот что-то из не видно, но я их где-то видел. И они вызывались без namespace, я еще думаю, ну ничего себе, наверное, ошибка. Смотрю – нет, оно так и должно быть. Один action только есть в этом application, сейчас в layout’е глянем. Helper’ы все…

zhorzh – Понятно, слушай, по поводу Zend DB. Какие там корневые отличия были сделаны, ты не помнишь?

netandreus – Я не знаю, я вообще Zend_DB перестал интересоваться давно в связи с переходом на Doctrine, и я не знаю, что там. Я знаю, что, по-моему, они там сменили pattern…вобщем, не буду врать. Там был Table Gateway, стал Mapper. Этой темой я не интересуюсь, но, судя по всему, у вас там в Zend_DB тоже будет много всякой работы.

hackPNZ – Я чувствую опять в сторону, как в Symfony, они, скорее всего, это сделали, там тоже похожая такая штука, насколько я помню.

netandreus – А в Symphony Doctrine же там, там все классно.

hackPNZ – Да? А я смотрел у них там что-то свое было. То есть они только Doctrine используют и все?

netandreus – Нет, у них в версии 1 они использую Doctrine / Propel. Потом, видимо, их заколебало поддерживать этот пропил, и они во второй версии оставили только Doctrine. Там можно опционально подрубить…

hackPNZ – Я уже давно смотрел и что-то такое уже видел, название какое-то неблагозвучное, чисто так по-русски «Пропил».

netandreus – Где твои модели? – Пропил.

zhorzh – Пропили и пропил… мне тоже кажется, и мы, конечно, побеседуем на эту тему. Мне тоже вот Doctrine как-то больше импонирует как слой доступа к базе данных. По большому счету, это же заимствованное все из Java, от Hibernate Java Persistence API. Поэтому, если уже и усложнять свой слой базы данных, переходить с Active Record или с Table Gateway, то на боле известные методологии, потому что в Java там второго не дано – либо есть, либо нет.

netandreus — Либо пропил. Кстати, в доктрине у нас тоже раньше была миграция – мы переходили с первой Doctrine на вторую Doctrine. Я скажу, что тоже они там много чего нафигачили, там несколько концепций поменялось. У них в первой доктрине были базовые модели, тоненькие, которые по сути были таблицами отражений полей – такой-то столбец отражается в такое-то свойство объекта. И были у них основные модели, где уже вся логика была. И очень часто в основных моделях и сидел сервисный слой. А сейчас во второй доктрине они пошли умнее. У них просто были модели? и там у них сидит все вот это отображение. А вся бизнес-логика, и вообще вся логика, она ушла уже в репозитарий. У них сервисный слой во второй Doctrine это по сути так называемый репозитарий. Это на тему «куда нам девать сервисный слой, если мы переходим на вторую Doctrine?» Место уже в принципе есть, и там живется довольно-таки неплохо. И опять же, там могут быть репозитарии к ORM и к ODM, и они все получаются очень красивыми. Быстро можно к ним выйти, не то, что там через 10 вызовов.

hackPNZ – В принципе, все-таки такая вот радостная нота, то есть мы с вами не нашли такого вот убер-подхода, убер-решения, чтобы там нажать одну кнопочку и сделать миграцию с ZF1 в ZF2, но мне нравится, что много что было сделано во втором ZF. Даже тот же переход на те же Name Spaces проще, это не такая жесть, как если бы они начали делать что-то такое непонятное, все-таки все framework’и основные – Symfony и ZF – приходят к тому, что появляется стандартизация, есть стандарты, которые сам язык привносит, PHP я имею в виду – name spaces PSR-0 по структуре хранения своих классов и так далее. Хочется верить, что миграция будет не дико болезненная, посмотрим, может community здесь будет более активной, средства какие-то появятся, tools’ы новые классные. Я вам желаю удачи в переходе в ваших проектах, я посмотрю еще у себя, что в плане сервисов, у меня пока что оно сбоку все используется, поэтому у меня такой головной боли и задачи не стоит. Спасибо, что рассказали, что пришли. По поводу Zend Framework, интересно было послушать, что сейчас происходит в сообществе и про мероприятия. Я думаю, что Андрей со мной согласится, да и Георгий тоже, и это понятно, что нужно ездить на подобные конфы, особенно учитывая то, что сейчас происходит обкатка и отработка хороших практик использования этой новой версии Framework. Здесь действительно польза большая, очень много тем, и, пожалуй, даже времени не хватает, чтобы обсудить все как на конференциях этих и при встрече.

netandreus – Конечно, не хватает, потому что столько вопросов, вот как Георгий сейчас задает практические вопросы, тоже очень хочется услышать про практику. Какие-то манулы можно найти и почитать, а хочется узнать, вот была какая-то задача, человек столкнулся, человек ее решил, посмотрел все решения и сам что-то придумал. Да, Антон, конечно, надо ездить, просто не всегда есть возможность еще. Что меня порадовало – конференция была однопоточная, я помню я приехал как на 01.09.54 дефконф, и там logo потоков, и все хочется посмотреть, и все интересно, и вообще, взрыв мозга! А тут один поток, и сидишь себе спокойно все слушаешь.

antonkopylov – Да, и проблемы выбора нет, куда метнуться. Все доклады ты послушал, это да, это хорошо.

zhorzh – Я надеюсь, что к весне, когда будет ZF конф в России, мы уже наберем побольше опыта миграции на ZF 2, кто-то из докладчиков, возможно, сам Андрей подъедет на конференцию с докладом о миграции…

netandreus – Георгий, ее Wizartec будет организовывать?

zhorzh – Да, да.

netandreus – Классно.

zhorzh – Возможно кто-то из ZF’овцев снова подъедет повещать, хотелось бы, чтобы это был сам Мэтью.

antonkopylov – Да, конечно, Мэтью было бы здорово, Мэтью там будет просто нарасхват, потому что у всех по любому, вопросы к нему есть. Хотелось бы пожелать, чтобы было в Питере, мне очень понравилась именно Питерская конфа. Поживем, увидим. Я с радостью тоже приеду. Может быть, на какую-то смежную тему выступлю по поводу использования чего-нибудь такого NoSQL’енного с Zend’ом, если будет что рассказать.

hackPNZ – Вобщем, надеюсь, конца света не будет, как уже на прошедшей конференции по Zend Framework объявили, заранее сообщили, что конца света не будет

antonkopylov – Так, а мы уже отмечать собрались

hackPNZ – Да, ну придется вас расстроить, видишь, не получается, поэтому в 2013 году мы соберемся и что-то хорошее опять выработаем и обсудим, и расскажем о ZF конф, я надеюсь. Я и в подкасте это все освещу. По поводу Zend Framework просили, получите! Я думаю, что и слушателям, которые не только вот так плотно работают с Zend Framework, было интересно слушать, что мы рассказали. Многие вещи, затронутые и обсуждаемые, они довольно-таки общие, и во многом они могут перекликаться с другими framework’ами, я думаю, будет интересно, потому что не слишком уж совсем узко специализированно все рассказывали. Спасибо еще раз, ребята, что пришли, я обязательно буду стараться звать вас еще.

netandreus — Спасибо, что пригласил, Антон. Всегда рады!

hackPNZ – Да, тем для обсуждения много, и всегда приятно обсудить с умными людьми, уже потом у меня в голове мысли какие-то появляются, я, допустим, хожу целую неделю у меня внезапно свои какие-то начинаются мозговые штурмы и движения внутренние – как я хочу сделать, ой, а можно же вот так. Вот так, давайте на этом закруглимся, спасибо всем, всем пока, услышимся!

netandreus – Пока, пока!

Share