• Решение проблем организации бизнес-логики в PHP или как пойти своим путем
    0

    Ну это смотря какое приложение. Более того, я еще раз подчеркну, что это лишь один пример, который говорит про то, что по крайней мере в тех обстоятельствах пришлось стандартное поведение какого-то компонента изменить, чтобы удовлетворить требованиям так скажем протокола с конкретным заказчиком.

  • Решение проблем организации бизнес-логики в PHP или как пойти своим путем
    0
    Скорее логики представления. Вы же конвертируете там представление данных а не бизнес логикой занимаетесь

    Логика представления специфична для клиента, который присылает данные, а не для протокола, которым клиент пользуется. Причем это один из с пару десятков вариантов специфичности десериализации. Этот код нельзя будет применить для другого клиента. Так что я думаю, что это именно бизнес-логика. Возможно я не прав.


    То есть под сегментированием логики вы подразумеваете случаи когда логика вытекает наружу? Ну мол нарушение инкапсуляции, закона Деметры, open/close и srp?

    Если говорить известными терминами, то да. Оно самое.


    в чем это выражается?

    Это когда ты смотришь на исходники и понимаешь, можно бы было обойтись меньшим количеством байт ))


    Опять же, мне сложно представить себе подобное разделение ответственности усложняет код. Было бы все же интересно хотя бы приблизительно разобрать ваш случай.

    Наверное, лучше привести в пример то, как обычно проходит code review. Обычно приходит набор файлов с диффом, из которого довольно сложно понять как точечные изменения позволяют решить поставленную задачу. Конечно, бывают и другие, где понятно, что и почему изменено и почему этот дифф оптимально решает задачу. Но таких PR мало. Увы.


    Поэтому мне лично очень интересно как нужно проектировать систему, которая на достаточно большой перспективе позволяет хорошо организовывать бизнес-логику. И было бы очень круто, если подход не будет требовать писать тонны бойлерплейта.

  • Решение проблем организации бизнес-логики в PHP или как пойти своим путем
    0

    Я имею в виду ситуацию, когда у нас есть, например, шина событий и, как это часто бывает, задачи, которые надо сделать вчера.


    Но начать лучше с начала:


    Разберу пример с обновлением какой-то сущности, потому что чтение не так наглядно, хотя и там бывают приколюхи.


    1. Вначале не было ничего
    2. Спроектировали идеальную систему с достаточным потенциалом к расширению с учетом всех изначальных требований, где запросы пользователя обрабатываются четко и ровно в том домене, где следует.
    3. роутинг, десериализаци, валидация, если нужно, выборка нужной сущности — POST без выборки или PUT/PATCH для обновления, сохранение, выдача результата — редирект на другой роут или просто страница со статусом выполненного запроса, или сериализация ответа в случае API

    Потом приходят требования, которые можно быстро внедрить, например, прям на уровне (де)сериализации. В моей практике это было требование воспринимать строки true\false\0\1 как bool. Это часть бизнес-логики, потому что отправляющая сторона уже написана и формирует запросы именно так. Другой пример, после сохранения новой сущности нужно тригерить обновление чего-то другого в системе. это очень просто делается добавлением еще одного события и эксклюзивного подписчика оного.


    В этих двух простых примерах бизнес-логика после внесения изменений теперь находится в двух частях и сходу не видно как без серьезного переписывания не сегментировать (логику). Вероятно, нужно держать разный набор схемы данных для разных слоёв — (де)сериализация, контроллер, дополнительные обработчики — и получится что-то типа middleware, но, кажется, что 1) код распухает и 2) система становится переусложненной со всеми вытекающими последствиями


    P.S.: прошу прощения за не очень спешный ответ.
    P.S.: Опыт проектирования у меня чуть более чем нулевой, поэтому я не стал приводить несколько разных примеров архитектуры, но, кажется, одного будет достаточно

  • Решение проблем организации бизнес-логики в PHP или как пойти своим путем
    +1

    Кажется, ни один из известных, по крайней мере из популярных, подходов проектирования не рассматривает задачу избежание сегментации бизнес-логики. Причем это про разные стэки верно.

  • Построение модульной архитектуры приложения на Forwarding-декораторах (авторский перевод)
    0

    Статья, содержащая в себе фразы типа "нативное наследование", изначально настраивает на недоверие.


    • Вмешиваться в иерархию типов кажется очень сомнительной идеей. Более того, определение кто кого расширяет противоречит идее использования интерфейсов. как самих по себе так и в составе SOLID.
    • Не являюсь большим знатоком ворпресса, но коль уж система имеет вполне определенное назначение, что упрекать её в ограниченном наборе хуков, наверное, неуместно.
    • минусы использования DI надуманные. Его (DI) в хороших реализация работа заканчивается на этапе компиляции зависимостей. А также под DI стилем имеется в виду что? Конфиги? или код? Если конфиги, то тут объяснение простое — явное указание зависимостей — это хорошая практика. Да, часто разработчики испытывают соблазн использовать магию в виде автовайринга но мы же знаем, что явное лучше неявного. Если код, то как правило нет никакого стиля, это просто обычные конструкторы, сеттеры или публичные методы с определенными сигнатурами. Это обычные пользовательские типы и DI тут просто как потребитель а не "требователь" архитектуры.

    Это навскидку.

  • Symfony Flex, как будет выглядеть ваше приложение с Symfony 4
    0

    Кстати да. на этот случай же уже есть секция bin (копирование все этих скриптов из пакета в проектный bin) к композере. если я ничего не путаю, к этому делу можно добавить условно безопасный запуск всего, что есть в проектном бине и будет уже что-то с чем можно работать. не надо перехреначивать конкретный фреймворк… на самом деле надо, конечно, но по другой причине 8)

  • Symfony Flex, как будет выглядеть ваше приложение с Symfony 4
    0

    имхо


    composition over inheritance

    как попытка упростить работу с symfony приложениям имеют опосредованное отношение, редкий бандл заставляет наследоваться от изкоробочных компонент\сервисов. Как правило, можно всё завернуть в нужный алиас или не очень геморно перегрузить


    Конечно же, если обсуждать этот принцип сам по себе, то его достоинства и минусы очевидны и сейчас, имхо, он более уместен, чем, например, лет 5-10 назад.

  • Symfony Flex, как будет выглядеть ваше приложение с Symfony 4
    0

    Сдаётся мне, что все фреймворки (соответствующие ообщества), которые в той или иной степени используют symfony-компоненты, должны разработать PSR для для публикации и подключения компонентов, на основе которых можно будет пилить как базовые скрипты (в композере или в конкретном фреймворке), так и кастомные (в конкретном проекте). Тогда можно будет говорить о реальном упрощении всей этой катавасии с подключением\отключением


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

  • Symfony Flex, как будет выглядеть ваше приложение с Symfony 4
    +3

    В этой части


    У Symfony достаточно громоздкий процесс установки внешних бандлов
    Упущен довольно важный кусок из истории возникновения composer-а

    Fun fact: Composer started as a conversation about how to generically install bundles/plugins/extensions for Symfony and phpBB.
    
    WTF fact: Neither Symfony nor phpBB uses Composer as a way to install its bundles/plugins/extensions.
  • Тёмный путь
    +3

    Кармы не хватает за этот камент вручить жирный плюс

  • Консоль в массы. Переход на светлую сторону. Bash
    0

    Я думаю, что вы еще просто не сталкивались с ситуациями, когда задачу надо решить минимальными средствами. в том числе с минимумом сторонних зависимостей.


    Да, в баше много чего нет. Мне, например, для удобства пришлось самому реализовать передачу внутрь функций и обратно из функций массивов. Точнее, закостылить (порядка 30 строк на всё), но это точно лучше, чем тянуть десятки и то и сотни мегабайт для подобного готового в питоне или чем-то еще более монструозном.

  • Кластер Docker Swarm за 30 секунд
    +1

    По состоянию на версию докера 1.12.2 вместо команды


    docker service tasks web

    надо использовать


    
    docker service ps web
  • PHP-Дайджест № 97 – интересные новости, материалы и инструменты (14 – 27 ноября 2016)
    +8

    Интересно, зачем нужно davidrjonas/composer-lock-diff если есть composer update (-vvv) --dry-run из коробки ?


    Причем это более безопасный способ увидеть, что обновится\обновилось

  • Консольные команды с PHPixie Console
    0

    Очевидно, что не хватает typehint-ов

  • Управление Docker проектом со множеством git репозиториев
    0

    имхо, от тэгов как правило все только усугубляется. по крайней мере это все сложно использовать если не заворачивать в зонтичные скрипты\бинари\пакетные_операции.


    Сам по себе ансибл — очень крутая штука. просто кривая обучения слегка недружелюбна )))

  • Управление Docker проектом со множеством git репозиториев
    +1

    Да, вот только у ансиблса задачи сильно фрагментированы обычно, а плейбуки — что-то типа монолита, причем по несколько штук на разные случаю
    Во-вторых, не знаю как вторая версия ансибла, но первая была почти всегда чуть менее чем стабильно. дебажить и подгадывать какие таски или плейбуки запилить… то еще удовольствие.


    Правда, всё выше сказанное, не про замену сабжа этого поста на ансибл, а просто про ансибл.

  • Управление Docker проектом со множеством git репозиториев
    +1

    Интересная штука! Как считаете, есть смысл писать подобные приложения на python\golang ?

  • Что собой представляют образы Docker none:none?
    0

    Какой версии у вас docker engine?
    Я проверил свою /var/lib/docker (ubuntu 14.04 и Docker version 1.11.2)
    у меня там


    • aufs
    • containers
    • image
    • network
    • tmp
    • trust
    • volumes

    Это я к чему… к тому, что у меня сложилось мнение, что с каждой новой версией в engine могут быть заметно большие изменения и соот. статьи-описания того как всё работает могут быть не очень полезными. Без претензии к этой статье, но вообще об актуальности.

  • PHPixie Social — простая интеграция с соцсетями
    0

    Увы, но я не могу аргументировано ответить — нет достаточных знаний вашего продукта. Хотелось бы обратить внимание, что главным в моем предыдущем сообщении был последний абзац.

  • PHPixie Social — простая интеграция с соцсетями
    0

    Ну вот зачем так? Я про обоснование потенциального велосипеда. Вероятно, есть более существенные причины у вашего решения, но представленные в каментах имхо сомнительны.


    Во-первых, разница между PSR-0 и PSR-4 минимальна, а если вы используете фичу optimized autoloader в композере, то вообще для работающего приложения не имеет значения (HybridAuth же работает, да?) как собственно и воообще следование PSR-0 или PSR-4


    Во-вторых, кроме HybridAuth есть еще как минимум HWIOAuth. Он не без проблем, но в целом тоже работает. В нем, кстати, не надо писать классы токена для сериализации, да и вообще работа с токенами полностью на нём.


    В-третьих, в том же HWIOauth есть почти все провайдеры которые требуются, а добавлять их на самом деле не так просто как кажется.


    HWIOauth я указываю только как пример, с которым хорошо знаком.


    А вообще вы же создаете собственную. комьюнити вокрут вашего фреймворка, если я не ошибаюсь, но с каждым новым стандартным решением (то, что решено коллегами из других комьюнити или вообще в мире PHP) у меня лично усиливается подозрение, что интегрировать ваше решение с решением не из ваших компонент, это задача нетривиальная. И, конечно, в такой ситуации лучше своё написать, чем подстраиваться под других.

  • Запросы к Rest API из JavaScript компактно и красиво
    +9

    Раскройте пожалуйста термин кошерного ООП ?

  • Создание блога на Symfony 2.8 lts [ Часть 2 ]
    +2

    Знаете, у вас в вашем блоге (в разделе IT) много чего занятного, не только по теме данной статьи. Там можно долго обсуждать и комментировать многие темы:


    • Почему я не использую тесты кода
    • Методологии разработки говно
    • ООП говно
    • Почему я не использую Twitter Bootstrap

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


    • бОльшая часть негатива адресована Yii. Видимо, потому что там наибольший опыт. Но Yii (особенно 1) — не самый лучший пример фреймворка, да простят меня разработчики, которые используют его.
    • вы часто делаете выводы из частного на общее. Например, пример плохого кода из приложения, которое написано с помощью какого-то фреймворка — не сам код фреймворка, а именно приложения! — для вас является показателем качества первого (фреймворка)

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


    вот немногое


    • методологию
    • тестирование
    • метрики кода
    • знание инструментов
    • возможности языка
    • алгоритмы
    • и т.д.

    Если по каким-то пунктах вы уходите так сказать в сторону и у вас появилось раздражение или плохие результаты (невозможность применять инструмент как хочется я также отношу к плохим результатам), это не значит что что-то из этого говно. Это значит, что где-то в применении подхода появился изъян. Важно, что тут речь о практике, а не о теории. И не надо всё месить в кучу. Надо "отдебажить" подход и посмотреть что из набора у вас работает не так как вы хотели и почему.


    Может вам ЯП надо поменять или какой-то инструмент. Но в любом случае это напрямую зависит от задачи, которую вы решаете в данный момент. Инструменты разные же для разных целей. Если вам для склеивания фарворовой кружки не полошел молоток или скальпель — это необязательно потому что они — говно. Просто для склеивания надо использовать другое!


    А вообще я согласен с мыслью, что фреймворки не надо использовать, но в том смысле, что так или иначе он у вас есть (50 КБ своей гордости), просто надо выбирать лучший, а лучший — это который помогает, а не мешает. В идеале вы его со временем просто не будете замечать.

  • Как нам помог Docker в написании тестов
    0
    zeliboba69
    Да, про тестирование моков я немного не в тему сказал. Задам другой вопрос ) не знаю как там в джава, но в php есть варианты проще перехватывать подобные обращения (у вас их к слову нет, вы поднимаете какой-то инстанс нужного сервиса) — SoftMocks или runkit. это инструменты которые перегружают библиотечные (недоступные в исходном виде) модули\функции, чтобы обеспечить как и в вашем случае — интеграционные тесты. Так вот привлечение докера (только для интеграционных тестов?) так как-бы немного сбоку смотрится странным решением.

    Может быть следует сделать сборку на docker-compose для нескольких окружений (dev, test, prod) где не потребуется использовать SimpleAerospikeClient а взаимодействие клиентов и их серверами будет обеспечено сетью, которую поднимает докер при запуске группы контейнеров? Это, скорее всего сложнее, но выглядит имхо канонично в рамках использования контейнеров

    а еще что у вас с фреймворком тестирования? Это JUnit? А есть ему альтернативы?
  • Как нам помог Docker в написании тестов
    +3
    Это из иллюстрации к корнею чуковскому. Для вас это бред, а для нас (постарше) это тест на школоло )) шутка, без обид.

    А если серьезно то тк автору у меня вопросы
    непонятно зачем так реализовывать модуль к фреймворку тестирования (у вас гольный junit или как?)

    Стал ли этот вспомогательный код частью приложения?

    Не похоже ли это на антипаттерн тестирование моков?
  • Инициализируемые контроллеры в Symfony и работа с аннотациями
    0
    И да, и нет. Они должны быть тонкими — поэтому нет, сам контроллер как сервис может иметь зависимости чтобы не обращаться в service locator по имени нужного сервиса, Да — потому что по той же причине. это просто request/response транслятор. + роутинг к action-ам. сам он ничего не должен уметь кроме serialize/deserialize запросов пользователя. Не само конечно же serialize/deserialize а первичную подготовку Request и «выплёвывания» Response или Exception.

    + для предобработки кстати уже есть функционал от Sensio — https://packagist.org/packages/sensio/framework-extra-bundle

    И вообще, аннотации — такая штука. Я бы лично без необходимости не использовал )

  • Инициализируемые контроллеры в Symfony и работа с аннотациями
    +1
    Контроллеры можно сервисами регистрировать. С какой угодно инициализацией.
  • Версионирование базы данных на лету
    0
    Я полагаю, что под DDL вы подразумеваете схему БД и маппинг внутри приложения (какие поля в коде если отображаются и как на колонки в таблицах БД)

    Если так, то этот diff — это две части

    1 — файлик с sql патчем
    2 — diff самого кода

    Как было указано чуть выше, Doctrine migrations — это на PHP. Вполне может быть, что есть реализации на других языках.
  • Версионирование базы данных на лету
    0
    doctrine migrations для многих sql — для postgres точно есть. Базовые возможности — миграция схемы данных на основе маппинга и текущей схемы в БД
  • RainyJs — как Angular, только для Ajax
    0
    ng-value, не?
  • Сравнение процесса перехода Angular2 приложения до версии beta.0 на языках Dart и TypeScript
    +1
    В кругу коллег и в беседах просто на тему фреймворки\не_фреймворки сформировалась очень простая мысль. В текущем виде фреймворки нужны по сути только для проброса зависимостей + бутстрап. Всё остальное (даже событийная шина, кстати) — это задача приложения и\или его компонентов. Причем это справедливо и для фронта и для бэка.

    Сам пишу давно на symfony (1*, 2* версии) + ангуляр 1 последние полгода.

    Отсюда ответ на вопрос «при каком размере приложения имеет смысл связываться с каким либо фреймворком» — как только самостоятельная поддержка и бутстрап начинают вызывать проблемы — надо использовать фреймворк. Конечно же, желательно это «как только» предсказать, чтобы не выполнять мартышкин труд — не переписывать инфраструктурный код.
  • Compalex: сравнение схем двух баз данных
    +1
    При всем уважении, это похоже на инструмент для решения симптомов, но не проблемы (расхождение схемы данных).

    Но даже без учета этого не легче ли было сделать консольное приложение? которое, кстати, может спрашивать реквизиты подключения к БД без необходимости хардкода их для скрипта.
  • Обзор каркасов приложений на Symfony2
    0
    А что, magento — всё?
  • Авторизация для API с помощью токенов
    0
    В данном посте как бы аутентификация описана, а не авторизация. Причем, как правильно заметил skobkin, не по канону.

    [капитан]
    Вообще, в плане безопасности приложение должно обеспечить два процесса — авторизация (register/login/logout) и аутентификацию.
    [/капитан]

    С этой точки зрения было бы интересно увидеть изящную реализацию этих частей приложения в виде стороннего бандла (двух бандлов?) с этим фукнционалом, которое можно легко интегрировать в приложение _без_ авторизации и аутентификации, а также с возможностью подстроить процесс под свои нужды. symfony даёт возможность реализовать это достаточно топорно (через перегрузку вендорного решения) и через события. Сам приступал к этой идее, пока что похвастаться почти нечем, кроме — github.com/hanovruslan/api-key-project

    P.S.: карма не позволяет ссылки ставить :)
  • Cовременный подход к HTTP с PHPixie и PSR-7
    0
    А разве голосование по PSR-7 не отменено? С объяснением, что нужно дорабатывать…
  • Симфония самоподдува
    0
    «контроллеры в котором пеут быть перегруженными» => «контроллеры в котором вполне вероятно могут быть перегруженными»
  • Симфония самоподдува
    –1
    А я еще добавлю ) но это больше к самому PHP относится, а не к symfony. Мне не очень нравится, что на расширение DSL как правило надо писать несколько новых классов + провязывать их в DI. Хотя скорее всего, это связано с моим уровнем программирования (сейчас запоем читаю paulgraham.com/articles.html ). Вероятно, в большом долгоиграющем приложении есть шанс и необходимость писать такие сервисы или даже компоненты, которые из конфигурации приложения обеспечат ядро приложения + надо будет на базе их (своих компонентов в частности и вендорных вообще) реализовать какие-то исключительные случаи.
  • Симфония самоподдува
    +3
    Без конкретики сложно (нужно ли вообще?) комментировать боль, которая добре разлита в данном посте, поэтому попробую сосредоточиться на чем-то конкретном.

    Про гугление

    В условиях, когда инет толстый и документация постоянно обновляется (что не совсем правда про библиотеки и фреймворки), чтение документации постепенно и уверенно прячется за фасадом «погуглить». Я лично четко наблюдаю подмену понятий, найти решение <-> где-то по гуглиить. Типичные задачи, которые описаны в блоке «Symfony-only developer», решаются знанием документации с сайта самой симфони и с доктрины. Не уверен, правда, насчет загрузки файла. Разработчики обоих систем предоставляют онлайн и оффлайн документацию. Далее всё сводится к необходимости\умению команды прикрутить конкретные компоненты к приложению.

    Про кастомизацию

    Старое доброе «вы просто не умеете их готовить» про сущности, связанные с БД. Думаю, бОльшая часть разработчиков (на любом языке программирования), использующих модели, которые связаны с каким-то постоянным хранилищем, согласится, что активная бизнес-логика (типа, юзер\статья сделай что-то поленое и сохранись), не должна (не «не может») располагаться в подобных моделях. Это логичнее и удобнее держать в сервисе, который несет ответственность за данную часть DSL. В терминологии symfony — это сервис, который непосредственно связан с определенным ресурсом приложения. Отсюда и «проблемы». Сделайте\используейте подходящий сервис, который инкапсулирует в себе нужный репозиторий и менеджер моделей, и не надо будет делать такой крюк с переопределением вендорных сервисов

    Про сложности symfony

    Компонент security пока что лично у меня вызывает боль. Как и Form. Но тоже относительно. Заявленные возможности работают как описано в документации. Если есть необходимость часто использовать динамические формы, то, наверное, имеет смысл подумать о написании своего бандла, который будет в себе инкапсулировать вашу боль.

    Я до сих пор имею к стэку компонентов symfony (кроме уже озвученных security и form) только одну претензию: Контроллеры не являются честными сервисами. Нельзя просто так взять и переопределить какой-то контроллер со своими экшенами. Надо либо использовать compiler pass, либо перегружать бандл. Может быть, можно как-то перехватить постоение стэка роутов и внедриьт туда свой перегруженный контроллер\экшен. Конечно же, это не так, если используется бандл, контроллеры в котором пеут быть перегруженными (Sylius). И всё равно, это не мешает использовать symfony.

    Если абстрагироваться от конкретных возможностей фреймворка, я думаю, что успех symfony не в последнюю очередь связан с DSL уровня обобщенного приложения (веб, консоль, демон). Речь не о full stack приложении, а о наборе компонентов.
  • Sublime Text 3 плагин «Symfony2 Override» для быстрого переопределения части бандлов
    +1
    Было бы интересно узнать о ваших исследованиях, если такие были, есть ли какие-то консольные (php app/console %command%) выполняющие подобные операции. Согласитесь, что в командном исполнении подобный функционал почти что нативный для приложения на базе symfony?
  • Процесс разработки и тестирования демонов
    0
    Интересно бы было узнать, как тестируются обновления, которые меняют поведение работающих демонов в данный момент на продакшене. Внутреннее версирование? Токенизация?
  • Понимая Docker
    0
    Согласен