Задать вопрос
  • Авторизация в одностраничных приложениях. WSSE, токены или OAuth?

    Fesor
    @Fesor Автор вопроса
    Старая добрав авторизация по токенам и OAuth2 там где появляется необходимость в SOA.
  • Mysql умеет сам делать merge index, но быстрее ли это?

    справедливости ради, с версии 5.6 умеет, но это не будет так же эффективно как составные индексы. Тут вопрос в количестве данных и индексов, насколько я понимаю merge index-ы стоит юзать когда у нас стоит выбор, либо сделать несколько составных индексов на все случаи жизни или же сделать отдельные индексы по полям которые учавствуют в условиях. Ну мол, может возникнуть ситуация при которой для 4-х полей нам нужно либо 16 составных индексов (крайний случай) либо 4 обычный. И если данных много то второй вариант как-то приятнее. Ну или опять же как первоначальный вариант когда логика поиска еще не проработана полностью.
  • Какие ЧПУ лучше для SEO?

    Иван: ну ок, я не сеошник и для меня все это темная магия. Если что делают маркетологи я еще могу как-то понять, но ваша работа для меня сплошь тайна и обряды, которые призваны обмануть алгоритмы поиска.
  • Ресурсоемкая функция подвешивает браузер?

    > нативную функцию map

    функция map не нативна и значительно медленнее for
  • В чем суть Yii2?

    Евгений Перин: если только начинаете - то значит вам это пока рано и профита это вам не даст. Из существующих - пожалуй Zend и Symfony. Хотя как по мне достаточно взять тот же Yii2 или Laravel, вклинить туда Doctrine и наслаждаться жизни.

    Как сказал Виталий Хоменко, идеальных фреймворков не бывает, у всех какие-то проблемы. Потому люди которых эти проблемы реально парят не используют фреймворки, только отдельных их компоненты и делают свои фреймворки под свою задачу. Но это штучное производство и нужно очень хорошо знать что ты делаешь. То есть нужно как минимум пару лет поработать с фреймворками что бы пройти эту стадию.
  • В чем суть Yii2?

    Виталий Хоменко: Можно поиграть в игру "Ищем нарушения принципов SOLID в архитектуре фреймворка". А так же почему Active Record для серьезных проектов это плохо.

    p.s. Я не хочу сказать что Yii2 это плохо, просто ООП и архитектура не самая сильная его сторона.
  • В чем суть Yii2?

    Если у вас ООП головного мозга (как у меня например) - то варианты с Yii отметаются сразу. Ну или почти сразу.
  • В чем суть Yii2?

    Ну так может стоит забить на Yii? Да и вообще на фреймворки, вы же можете функционал самостоятельно написать.
  • Какие сервисы используются при проектировании требований к ПО?

    Рустем Саиткулов: так а там можно посмотреть лог изменений? Я пока вижу только возможность посмотреть логи на основе сообщений при паблишинге, что меня лично не очень устраивает...
  • Стоит ли начинать учить Angular 1.x или дождаться 2.x и не забивать себе голову?

    ГЛЕБ ГЛЕБОВ: мм... откуда взяться нагрузке?

    babeljs.io - вперед к светлому будущему. На самом деле после перехода на ES2015 (или 6 + 7) меня впервые не тянет блевать от JS.
  • С какого фреймворка стоит начать (Yii, zend, symfony)?

    Kir ---: мм... вам я так понимаю нравится Yii или laravel4.... или pimple.... Я правильно вас понимаю что вместо конфигов, с которыми хоть как-то можно жить, вы предлагаете одно из двух:
    - писать тонны бойлерплейта на каждый класс, что как по мне хуже конфигов
    - завязать все компоненты фреймворка на контейнер и нарушить принцип ивенсии зависимостей. Что в итоге произойдет где-нибудь в проекте ибо разработчики ленивые существа. ну или вообще убойную комбинацию из регистри и фабрик явных.

    В Symfony при всей своей неудобности принцип инверсии зависимостей все же сохраняется, а это главное. То что конфиги не удобно поддерживать - повторюсь уже 4-ый раз (вы видимо не читаете то что я пишу), это все можно обойти использованием другого контейнера поверх стандартного.

    А как вам такой вариант:

    class Foo {
    
         public function __construct(Session $session){}
    }


    и конфиг ко всему этому:

    <?php
    
    return [
        Session::class => MySessionManagerImpl::class
    ];


    В итоге у нас одна строчка в конфиге, которая определяет что для такого-то интерфейса, на который завязазы все остальные компоненты, у нас такая-то реализация. И все. Больше ничего писать ненадо (если нет чего-то сложнее вроде передачи конфигов или параметров).

    Следствие использование DiC как в Sf2 прямое нарушение solID.

    Ммм... именно принцип сегрегации интерфейсов? Ну... в целом не думаю что sf/DiC подстегивает к этому разработчиков. Уж чаще можно встретить для начала нарушение принципа единой ответственности. По поводу того что народ чаще завязывается на конкретные имплементации и принебрегает силой интерфейсов - это беда не инструмента а головы. Опять же все это лего фиксится использованием другого контейнера и Symfony тут не причем.

    Но опять же, это один из компонентов который легко заменить на другой.

    По поводу инверсии зависимостей - как я уже писал выше - у sf с этим все ок, ничего не нарушается (я небыл уверен, выделили вы D или так просто опечаталось)
  • Какова скорость работы различных CMS?

    Most998: вообще ответ прост - под Wordpress есть огромное количество готовых решений и тех самых плагинов. Меня лично код WP вгоняет в дикую тоску и вызывает приступы мизантропии, но свои задачи оно решает.

    Есть скажем PicoCMS, крошечная CMS для бложиков и статических страничек. Социальную сеть на нем не построить (да, на WP этим занимаются, во всяком случае лет 6 назад это было модно). А есть Bolt, который построен на базе Symfony компонентов, использует composer и кривая изучения оного довольно высока. Зато эту CMS можно интегрировать в свои проекты относительно легко.
  • С какого фреймворка стоит начать (Yii, zend, symfony)?

    Kir ---:

    справедливости ради, в PHP нет такой вещи как "взять по типу", только строки. Так что все ок.

    За подобное создание сервисов на каждый чих нужно руки отрывать.

    Аргументируйте (или как минимум расскажите как надо, мне всегда интересно узнать мнение других людей о построении сервисного слоя приложения, именно как части модели предметной области). За что именно нужно отрывать руки? За то что вместо тупых классов менеджеров (по одному на каждую сущность, нарушая при этом single responsibility) у нас имеются четкое разграничение сервисов по фичам и каким-то особенностям бизнес логики? За то что всю бизнес логику и весь сервисный слой приложения можно покрыть юнит тестами без боли?

    Словом это все очень абстрактно. Ну и есть не нулевая вероятность что фразу "создать класс на каждый чих" вы восприняли уж сильно буквально.

    Опять же, что до конфигов - конфиги нужны, и я уже третий раз повторяю, вас никто нивчем не ограничивает. Можно хоть свой компайл пасс сделать который будет все "правильно" делать (я правда считаю это извращением), можно поставить другой контейнер (причем есть готовые интеграции, не нужно городить горы бойлерплейтов). Хотя да, согласен что контейнер зависимостей у симфони - самая неудачная его часть.

    Unit-Of-Work идёт с Doctrine, а не с Sf2. Doctrine не часть Sf2.

    Ну Doctrine идет в symfony-standard-edition из коробки. Так что я считаю это частью фреймворка. Ибо если это не так, то Symfony можно воспринимать только как набор компонентов и не более, и тогда любые притензии к отдельным компонентам можно считать фарсом.

    Повторюсь, мне сейчас нравится идея вообще обходиться без full-stack фреймворков и использовать набор компонентов. Но новичкам, а вопрос задавался в этом контексте, этого следует избегать и для начала разобраться в основной структуре приложения.

    p.s. А что вы предлагаете использовать новичкам которые, как правило, даже ООП толком не знают?
  • С какого фреймворка стоит начать (Yii, zend, symfony)?

    Kir ---: какая связь между DI и ActiveRecord? Я как пример приводил.

    Например по дефолту Symfony идет с не слишком удобным DiC, который, хоть и реально гибкий и крутой, заставляет разработчиков лениться при проектировании того же сервисного слоя (как правило им лень описывать на каждый чих новый севис и появляются убогие "Менеджеры". Зато опять же из коробки Symfony идет с доктриной, которая обеспечивает persistence ignorance за счет использования Unit-of-work.

    Если брать какой-нибудь Laravel или Yii - там разработчики вдохновлялись RoR, и по итогу в комплекте поставки идет сносный IoC с автоконфигурированием. Но в то же время по дефолту там идет богомерзский ActiveRecord. В итоге можно и на нем сделать все хорошо, оборачивать все в транзакцию и работать через aggregate-root и использовать модели ORM как DTO, но это уже реально сложно и в 99% случаев будет считаться оверхэдом.

    А теперь давайте прикинем, что влияет больше непосредственно на код проекта? Использование ActiveRecord вместо Doctrine, где все это добро можно вынести в отдельный слой и вообще не завязывать на нее код проекта, или же DiC, который влияет только на удобство использования. При том что для Symfony есть autowire-bundle-ы, которые реализуют автоконфигурирование, пусть и кривенько. Можно запариться и сделать что-то свое. А можно вообще не париться и поставить PHP-DI + Symfony2 bridge и жить себе припиваючи. В этом плане к слову Zend выигрывает, так как у него и IoC как надо и доктрину можно легко прикрутить.

    Разработчики знаете ли, могут с Symfony выкидыать лишнее и оставлять то что им нужно. Есть проекты где от Symfony с течением времени осталось только HttpKernel и HttpFoundation. Раутинг сменен на FastRoute, формы и валидатор выкинуты (вся валидация идет через использование VO и внутри модели предметной области (в сервисах, в самих сущностях).

    ну и опять же речь в вопросе шла о первом фреймворке, да и ответ этот я писал 2 года с лишнем назад. Тогда тот же Laravel был еще зеленым.
  • С какого фреймворка стоит начать (Yii, zend, symfony)?

    Kir ---: кто такой Файлер?

    Может кто-нибудь объяснить когда разработчики начнут думать своей головой? Ну да, у них DI реализован так как реализован, зато это позволяет компилить оный а не кешировать. Ну и дополнительные плюшки. + вам никто не мешает использовать любой другой поверх симфоневского, я вот PHP-DI юзаю.

    Что до "маркетинга", лучше уже кривой DI чем Active Record всюду.