Какой версии у вас docker engine?
Я проверил свою /var/lib/docker (ubuntu 14.04 и Docker version 1.11.2)
у меня там
aufs
containers
image
network
tmp
trust
volumes
Это я к чему… к тому, что у меня сложилось мнение, что с каждой новой версией в engine могут быть заметно большие изменения и соот. статьи-описания того как всё работает могут быть не очень полезными. Без претензии к этой статье, но вообще об актуальности.
Увы, но я не могу аргументировано ответить — нет достаточных знаний вашего продукта. Хотелось бы обратить внимание, что главным в моем предыдущем сообщении был последний абзац.
Ну вот зачем так? Я про обоснование потенциального велосипеда. Вероятно, есть более существенные причины у вашего решения, но представленные в каментах имхо сомнительны.
Во-первых, разница между PSR-0 и PSR-4 минимальна, а если вы используете фичу optimized autoloader в композере, то вообще для работающего приложения не имеет значения (HybridAuth же работает, да?) как собственно и воообще следование PSR-0 или PSR-4
Во-вторых, кроме HybridAuth есть еще как минимум HWIOAuth. Он не без проблем, но в целом тоже работает. В нем, кстати, не надо писать классы токена для сериализации, да и вообще работа с токенами полностью на нём.
В-третьих, в том же HWIOauth есть почти все провайдеры которые требуются, а добавлять их на самом деле не так просто как кажется.
HWIOauth я указываю только как пример, с которым хорошо знаком.
А вообще вы же создаете собственную. комьюнити вокрут вашего фреймворка, если я не ошибаюсь, но с каждым новым стандартным решением (то, что решено коллегами из других комьюнити или вообще в мире PHP) у меня лично усиливается подозрение, что интегрировать ваше решение с решением не из ваших компонент, это задача нетривиальная. И, конечно, в такой ситуации лучше своё написать, чем подстраиваться под других.
Знаете, у вас в вашем блоге (в разделе IT) много чего занятного, не только по теме данной статьи. Там можно долго обсуждать и комментировать многие темы:
Почему я не использую тесты кода
Методологии разработки говно
ООП говно
Почему я не использую Twitter Bootstrap
Не смотря на то, что с некоторыми тезисами (но им не хватает должного раскрытия) я лично как-бы согласен, но в принципе наблюдается сумбурность вообще по многим темам в целом и по фреймворкам в частности:
бОльшая часть негатива адресована Yii. Видимо, потому что там наибольший опыт. Но Yii (особенно 1) — не самый лучший пример фреймворка, да простят меня разработчики, которые используют его.
вы часто делаете выводы из частного на общее. Например, пример плохого кода из приложения, которое написано с помощью какого-то фреймворка — не сам код фреймворка, а именно приложения! — для вас является показателем качества первого (фреймворка)
Я немного покапитаню, но для эффективного использования сабжа как и вообще фреймворков каких-либо надо много чего учитывать
вот немногое
методологию
тестирование
метрики кода
знание инструментов
возможности языка
алгоритмы
и т.д.
Если по каким-то пунктах вы уходите так сказать в сторону и у вас появилось раздражение или плохие результаты (невозможность применять инструмент как хочется я также отношу к плохим результатам), это не значит что что-то из этого говно. Это значит, что где-то в применении подхода появился изъян. Важно, что тут речь о практике, а не о теории. И не надо всё месить в кучу. Надо "отдебажить" подход и посмотреть что из набора у вас работает не так как вы хотели и почему.
Может вам ЯП надо поменять или какой-то инструмент. Но в любом случае это напрямую зависит от задачи, которую вы решаете в данный момент. Инструменты разные же для разных целей. Если вам для склеивания фарворовой кружки не полошел молоток или скальпель — это необязательно потому что они — говно. Просто для склеивания надо использовать другое!
А вообще я согласен с мыслью, что фреймворки не надо использовать, но в том смысле, что так или иначе он у вас есть (50 КБ своей гордости), просто надо выбирать лучший, а лучший — это который помогает, а не мешает. В идеале вы его со временем просто не будете замечать.
zeliboba69
Да, про тестирование моков я немного не в тему сказал. Задам другой вопрос ) не знаю как там в джава, но в php есть варианты проще перехватывать подобные обращения (у вас их к слову нет, вы поднимаете какой-то инстанс нужного сервиса) — SoftMocks или runkit. это инструменты которые перегружают библиотечные (недоступные в исходном виде) модули\функции, чтобы обеспечить как и в вашем случае — интеграционные тесты. Так вот привлечение докера (только для интеграционных тестов?) так как-бы немного сбоку смотрится странным решением.
Может быть следует сделать сборку на docker-compose для нескольких окружений (dev, test, prod) где не потребуется использовать SimpleAerospikeClient а взаимодействие клиентов и их серверами будет обеспечено сетью, которую поднимает докер при запуске группы контейнеров? Это, скорее всего сложнее, но выглядит имхо канонично в рамках использования контейнеров
а еще что у вас с фреймворком тестирования? Это JUnit? А есть ему альтернативы?
И да, и нет. Они должны быть тонкими — поэтому нет, сам контроллер как сервис может иметь зависимости чтобы не обращаться в service locator по имени нужного сервиса, Да — потому что по той же причине. это просто request/response транслятор. + роутинг к action-ам. сам он ничего не должен уметь кроме serialize/deserialize запросов пользователя. Не само конечно же serialize/deserialize а первичную подготовку Request и «выплёвывания» Response или Exception.
+ для предобработки кстати уже есть функционал от Sensio — https://packagist.org/packages/sensio/framework-extra-bundle
И вообще, аннотации — такая штука. Я бы лично без необходимости не использовал )
В кругу коллег и в беседах просто на тему фреймворки\не_фреймворки сформировалась очень простая мысль. В текущем виде фреймворки нужны по сути только для проброса зависимостей + бутстрап. Всё остальное (даже событийная шина, кстати) — это задача приложения и\или его компонентов. Причем это справедливо и для фронта и для бэка.
Сам пишу давно на symfony (1*, 2* версии) + ангуляр 1 последние полгода.
Отсюда ответ на вопрос «при каком размере приложения имеет смысл связываться с каким либо фреймворком» — как только самостоятельная поддержка и бутстрап начинают вызывать проблемы — надо использовать фреймворк. Конечно же, желательно это «как только» предсказать, чтобы не выполнять мартышкин труд — не переписывать инфраструктурный код.
При всем уважении, это похоже на инструмент для решения симптомов, но не проблемы (расхождение схемы данных).
Но даже без учета этого не легче ли было сделать консольное приложение? которое, кстати, может спрашивать реквизиты подключения к БД без необходимости хардкода их для скрипта.
В данном посте как бы аутентификация описана, а не авторизация. Причем, как правильно заметил skobkin, не по канону.
[капитан]
Вообще, в плане безопасности приложение должно обеспечить два процесса — авторизация (register/login/logout) и аутентификацию.
[/капитан]
С этой точки зрения было бы интересно увидеть изящную реализацию этих частей приложения в виде стороннего бандла (двух бандлов?) с этим фукнционалом, которое можно легко интегрировать в приложение _без_ авторизации и аутентификации, а также с возможностью подстроить процесс под свои нужды. symfony даёт возможность реализовать это достаточно топорно (через перегрузку вендорного решения) и через события. Сам приступал к этой идее, пока что похвастаться почти нечем, кроме — github.com/hanovruslan/api-key-project
А я еще добавлю ) но это больше к самому PHP относится, а не к symfony. Мне не очень нравится, что на расширение DSL как правило надо писать несколько новых классов + провязывать их в DI. Хотя скорее всего, это связано с моим уровнем программирования (сейчас запоем читаю paulgraham.com/articles.html ). Вероятно, в большом долгоиграющем приложении есть шанс и необходимость писать такие сервисы или даже компоненты, которые из конфигурации приложения обеспечат ядро приложения + надо будет на базе их (своих компонентов в частности и вендорных вообще) реализовать какие-то исключительные случаи.
Интересная штука! Как считаете, есть смысл писать подобные приложения на python\golang ?
Какой версии у вас docker engine?
Я проверил свою /var/lib/docker (ubuntu 14.04 и Docker version 1.11.2)
у меня там
Это я к чему… к тому, что у меня сложилось мнение, что с каждой новой версией в engine могут быть заметно большие изменения и соот. статьи-описания того как всё работает могут быть не очень полезными. Без претензии к этой статье, но вообще об актуальности.
Увы, но я не могу аргументировано ответить — нет достаточных знаний вашего продукта. Хотелось бы обратить внимание, что главным в моем предыдущем сообщении был последний абзац.
Ну вот зачем так? Я про обоснование потенциального велосипеда. Вероятно, есть более существенные причины у вашего решения, но представленные в каментах имхо сомнительны.
Во-первых, разница между PSR-0 и PSR-4 минимальна, а если вы используете фичу optimized autoloader в композере, то вообще для работающего приложения не имеет значения (HybridAuth же работает, да?) как собственно и воообще следование PSR-0 или PSR-4
Во-вторых, кроме HybridAuth есть еще как минимум HWIOAuth. Он не без проблем, но в целом тоже работает. В нем, кстати, не надо писать классы токена для сериализации, да и вообще работа с токенами полностью на нём.
В-третьих, в том же HWIOauth есть почти все провайдеры которые требуются, а добавлять их на самом деле не так просто как кажется.
HWIOauth я указываю только как пример, с которым хорошо знаком.
А вообще вы же создаете собственную. комьюнити вокрут вашего фреймворка, если я не ошибаюсь, но с каждым новым стандартным решением (то, что решено коллегами из других комьюнити или вообще в мире PHP) у меня лично усиливается подозрение, что интегрировать ваше решение с решением не из ваших компонент, это задача нетривиальная. И, конечно, в такой ситуации лучше своё написать, чем подстраиваться под других.
Раскройте пожалуйста термин кошерного ООП ?
Знаете, у вас в вашем блоге (в разделе IT) много чего занятного, не только по теме данной статьи. Там можно долго обсуждать и комментировать многие темы:
Не смотря на то, что с некоторыми тезисами (но им не хватает должного раскрытия) я лично как-бы согласен, но в принципе наблюдается сумбурность вообще по многим темам в целом и по фреймворкам в частности:
Я немного покапитаню, но для эффективного использования сабжа как и вообще фреймворков каких-либо надо много чего учитывать
вот немногое
Если по каким-то пунктах вы уходите так сказать в сторону и у вас появилось раздражение или плохие результаты (невозможность применять инструмент как хочется я также отношу к плохим результатам), это не значит что что-то из этого говно. Это значит, что где-то в применении подхода появился изъян. Важно, что тут речь о практике, а не о теории. И не надо всё месить в кучу. Надо "отдебажить" подход и посмотреть что из набора у вас работает не так как вы хотели и почему.
Может вам ЯП надо поменять или какой-то инструмент. Но в любом случае это напрямую зависит от задачи, которую вы решаете в данный момент. Инструменты разные же для разных целей. Если вам для склеивания фарворовой кружки не полошел молоток или скальпель — это необязательно потому что они — говно. Просто для склеивания надо использовать другое!
А вообще я согласен с мыслью, что фреймворки не надо использовать, но в том смысле, что так или иначе он у вас есть (50 КБ своей гордости), просто надо выбирать лучший, а лучший — это который помогает, а не мешает. В идеале вы его со временем просто не будете замечать.
Да, про тестирование моков я немного не в тему сказал. Задам другой вопрос ) не знаю как там в джава, но в php есть варианты проще перехватывать подобные обращения (у вас их к слову нет, вы поднимаете какой-то инстанс нужного сервиса) — SoftMocks или runkit. это инструменты которые перегружают библиотечные (недоступные в исходном виде) модули\функции, чтобы обеспечить как и в вашем случае — интеграционные тесты. Так вот привлечение докера (только для интеграционных тестов?) так как-бы немного сбоку смотрится странным решением.
Может быть следует сделать сборку на docker-compose для нескольких окружений (dev, test, prod) где не потребуется использовать SimpleAerospikeClient а взаимодействие клиентов и их серверами будет обеспечено сетью, которую поднимает докер при запуске группы контейнеров? Это, скорее всего сложнее, но выглядит имхо канонично в рамках использования контейнеров
а еще что у вас с фреймворком тестирования? Это JUnit? А есть ему альтернативы?
А если серьезно то тк автору у меня вопросы
непонятно зачем так реализовывать модуль к фреймворку тестирования (у вас гольный junit или как?)
Стал ли этот вспомогательный код частью приложения?
Не похоже ли это на антипаттерн тестирование моков?
+ для предобработки кстати уже есть функционал от Sensio — https://packagist.org/packages/sensio/framework-extra-bundle
И вообще, аннотации — такая штука. Я бы лично без необходимости не использовал )
Если так, то этот diff — это две части
1 — файлик с sql патчем
2 — diff самого кода
Как было указано чуть выше, Doctrine migrations — это на PHP. Вполне может быть, что есть реализации на других языках.
Сам пишу давно на symfony (1*, 2* версии) + ангуляр 1 последние полгода.
Отсюда ответ на вопрос «при каком размере приложения имеет смысл связываться с каким либо фреймворком» — как только самостоятельная поддержка и бутстрап начинают вызывать проблемы — надо использовать фреймворк. Конечно же, желательно это «как только» предсказать, чтобы не выполнять мартышкин труд — не переписывать инфраструктурный код.
Но даже без учета этого не легче ли было сделать консольное приложение? которое, кстати, может спрашивать реквизиты подключения к БД без необходимости хардкода их для скрипта.
[капитан]
Вообще, в плане безопасности приложение должно обеспечить два процесса — авторизация (register/login/logout) и аутентификацию.
[/капитан]
С этой точки зрения было бы интересно увидеть изящную реализацию этих частей приложения в виде стороннего бандла (двух бандлов?) с этим фукнционалом, которое можно легко интегрировать в приложение _без_ авторизации и аутентификации, а также с возможностью подстроить процесс под свои нужды. symfony даёт возможность реализовать это достаточно топорно (через перегрузку вендорного решения) и через события. Сам приступал к этой идее, пока что похвастаться почти нечем, кроме — github.com/hanovruslan/api-key-project
P.S.: карма не позволяет ссылки ставить :)