Как получать точный fingerprint браузера?

Tails + TorBrowser дают идентичные отпечатки вне зависимости от машины, если не менять размер окна.

И правильно. Спамеры под тором отправляются в бан, а с ними и те кто пользуются тором ибо нефиг.

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

С этим тоже можно бороться.

Вообще, лучший способ спрятаться, это не прятаться за Tor, noscropt и doNotTrack, а наоборот, использовать наиболее популярное устройство с наиболее популярным браузером. Тот же iPhone.

Как получать точный fingerprint браузера?

Автор спрашивает есть ли аналог Fingerprintjs2 и вы кидаете ему ссылку на тот же Fingerprintjs2. Гениально.

Не работает код, когда поместил его в функцию php. Почему так?

edward_freedom, тогда передавайте её в аргументах. У вас не существует переменная $vk в теле функции

Как правильно реализовать теги в Symfony?

Flying, alexg-nn, я это реализовывал через доменные события. Советую посмотреть
https://github.com/gpslab/domain-event-bundle

Как делать пакеты как у Symfony?

Правильно понимаю, у вас структура аналогичная тому, что я привел? Т.е. внутри монорепозитория, непосредственно в директорииsrc классы не по PSR (присутствует что-то вроде framework-bundle/src/?

BoShurik, нет. Всё по PSR. Структуру я описал в первом комментарии.

Как делать пакеты как у Symfony?

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

Вообще-то будет работать. У меня работает не первый год в нескольких проектах. Но не суть. Можно организовать код и в самостоятельные бандлы и хранить тесты в бандлах.

Скоро не будут :)

Removed support for bundle:controller:action syntax to reference controllers.

Спасибо. Не знал.

С появлением _instanceof и !taggedCompilerPass уже и не нужны. Я ими давно не пользовался, по крайней мере.

Согласен. Это хорошие функции. Я еще по привычке пишу CompilerPass, особенно в публичных бандлах где нужна обратная совместимость. Согласен с вами, наверное можно отказаться от бандлов в проекте.

Как делать пакеты как у Symfony?

Какие нюансы?

Нюанс в том, что домен (domain), должен быть отделен от основного кода. Он должен быть независимым и легко переносимым на другой проект при необходимости. И это касается не только сущности, но и сервсисов предметной области. То есть, у вас будут сервсисы домена, инфраструктурыне сервисы, сервисы уровня приложения и сервсисы уровня представляени. Все эти сервисы по хорошему должны лежать отдельно друг от друга. То есть, по хорошему каждый модуль нужно разделить на несколько слоев:

• Presentation layer
  
• Application layer
  
• Domain layer
  
• Infrastructure layer
  
• Persistence layer
  

Есть еще такое понятие как Bounded Context. Можно создавать отдельные модули под каждый ограниченный контекст.

Но это ни в коем случае не требование. Это один из вариантов организации процесса разработки и структуры проекта. Не более того.

Я буду больше работать по паттерну CQRS.

Рекомендую посмотреть мои наработки в этом направлении https://github.com/gpslab/cqrs
На практике, мне показалось использование CQRS немного избыточным, хотя паттерн конечно интересный.

Как делать пакеты как у Symfony?

В защиту скажу, что c использованием монорепозитория по-другому не получится (ну или как минимум, у монорепы будет хитрувыдоманный автолоад, вместо лаконичного).

В защиту скажу, что исключить тесты из autoload можно гораздо проще и лаконичнее)))

{
    "autoload": {
        "psr-4": {
            "Sylius\\": "src/",
        }
    },
    "autoload-dev": {
        "psr-4": {
            "Sylius\\Tests\\": "tests/"
        }
    }
}

Как делать пакеты как у Symfony?

С появлением autowiring все бандлы заменяются, грубо говоря, одной строчкой

Ну практически. Такой подход не совсем верен потому, что в src у вас не только сервисы и регистрировать все подряд в контейнере неправильно. Есть конечно exclude:, но он не буде работать если делать иерархию модулей. Лучше в каждом модуле добавить свой конфиг:

services:
    _defaults:
        autowire: true
        autoconfigure: true
        public: false

    App\Blog\:
        resource: '../../../*'
        exclude: '../../../{DependencyInjection,Entity}'

Что бы не регистрировать конфиг каждого модуля в отдельности в Extension, можно прописать автоподключение в Kernel:

class Kernel extends BaseKernel
{
    private const CONFIG_EXTS = '.{php,xml,yaml,yml}';

    protected function configureContainer(ContainerBuilder $container, LoaderInterface $loader)
    {
        // ...

        // load configs from modules
        $loader->load($src_dir.'/*/Resources/config/*'.self::CONFIG_EXTS, 'glob');
    }
}

Большинство бандлов/модулей у вас будет пустыми, но в некоторых вам все же понадобится использовать Extension и CompilerPass. И придется объявлять модуль как бандл. Я считаю, что лучше сразу объявлять все модули как бандлы, что бы было единообразие.
К тому же, ссылаться на контроллер из модуля будет удобнее если модуль будет бандлом. Сравните 2 записи:

{# @controller AppBlogBundle:Home:index #}
{# @controller AppBundle:Blog/Controller/Home:index #}

Как делать пакеты как у Symfony?

Точно. Забыл как это называется. "монорепозиторий" Спасибо @BoShurik
Максим можно погуглить о преимуществах и недостатках монорепозиториев.

Как делать пакеты как у Symfony?

Максим, я ответил вам в другой ветке обсуждения

Как делать пакеты как у Symfony?

Теперь понял, что такое бандл окончательно. Это получается как адаптер под какой-то фреймворк, необязательно симфони.

Все правильно)))

Это очень важный комментарий) У меня тоже возникал этот вопрос и это правда лишний гемор. Об этом я долго думал. Было решение на эту тему сначала клонировать в проект репозиторий в какую-то папку, например, пакеты. Уже от туда к фреймфорку подключать как локальный репозиторий.

Можно использовать git submodules или устанавливать компоненты через composer install --prefer-source. Правда composer по моему устанавливает репозитории из http в read-only режиме и вам придется заменить установленные пакеты на обычный ssh.

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

Теперь окончательно понял, что это нужно делать именно так. Можете ли скинуть пару ссылок на подобную архитектуру из открытого проекта, если у вас такой есть. Или же пример чужого проекта. Есть небольшие вопросу по этому. Если с контроллерами, сущностями, сервисами всё понятно, то как работать с ресурсами, видами (шаблонизаторами), переводами. их тоже нужно хранить в src/Events или же они будут общими для всего приложения? Было бы не плохо всё таки ссылочку) Хочется начать проект качественно сразу. А пока не очень представляю архитектуру таких сервисов

BoShurik скидывал ссылку на Sylius . Это то, о чём вы говорите или нет?

Открытых/публичных примеров у меня нет, но пример с Sylius от BoShurik действительно близок к этому.
Единственное, я бы не оформлял модуль как независимый компонент, то есть без LICENSE, composer.json, phpspec.yml.dist, phpunit.xml.dist и т.д.
Размещение тестов непосредственно в самом модуле довольно спорное решение. Я во всех проектах, бандлах, компонентах и т.д. придерживаюсь структуры:

/src/
/tests/

Где папка src содержит исходный код компонента, модуля и т.д., а папка tests содержит тесты этого компонента. Я не считаю правильным смешивать исходный код и тесты. Тоже касается модулей. К тому же это может затруднить запуск тестирования всего проекта если тесты зарыты куда-то глубоко. Я предпочитаю продублировать структуру папок со списком всех модулей из корневой папки проекта src в такую же корневую попку проекта tests. То есть, получается так:

src/Blog/Entity
src/Blog/Services
src/Events/Entity
src/Events/Services
tests/Blog/Entity
tests/Blog/Services
tests/Events/Entity
tests/Events/Services

Мой подход не истина в последней инстанции и кто-то может со мной не согласится и он может быть будет по своему прав.

Касательно переводов и шаблонов. На самом деле это и к тестам тоже относится. Пока вы работаете над проектом один, то вы можете спокойно зарывать шаблоны в модули, в папку src/Blog/Resources/templates.

Когда у вас в команде появится отдельный верстальщик, ему будет неудобно ковыряться в ваших PHP модулях. У него будет своя модульная верстка. Ему будет гораздо удобнее если все шаблоны будут лежать в одной корневой папке templates. Я рекомендую вынести шаблоны и организовать их по модулям, примерно в следующую структуру:

templates/Blog/index.html.twig
templates/Blog/layout.html.twig
templates/Events/index.html.twig
templates/Events/layout.html.twig
templates/base.html.twig
templates/index.html.twig
templates/layout.html.twig

То же касается переводов. Если у вас не будет выделенного переводчика, то удобнее хранить переводы в модулях. Тексты переводов будете писать вы сами и возможно вам будет удобнее хранить их вместе в src/Blog/Resources/translations/messages.ru.yml.
Выносить переводы всех модулей в отдельный большой файл messages.ru.yml я не советую. Лучше добавить для переводов translation domain по названию модуля и получить Blog.ru.yml и Events.ru.yml.
Если у вас будут отдельные переводчики, то им конечно тоже будет удобнее если все переводы будут лежать в одной папке, а не зарыты глубоко в модули.

Еще проговорю несколько нюансов.

Конфиги с регистрацией сервисов модулей лучше хранить непосредственно в самом модуле. Там вы пропишете autowire и autoconfigure с путями к сервисам в конкретном модуле. Там пропишете псевдонимы сервисов модуля и проставите теги сервсиам модуля. Я не советую регистрировать сервисы модуля в глобальном конфиге /config/services.yml.

Регистрировать бандл для Doctrine тоже лучше в самом модуле. Там же удобнее регистрировать свои DBAL типы для модулей. Не засоряйте глобальный конфиг.

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

Итого, структура проекта имеет вид примерно такой:

src/Blog/Controller/
src/Blog/Entity/
src/Blog/Services/
src/Blog/Resources/config/doctrine.yml
src/Blog/Resources/config/services.yml
src/Blog/Resources/translations/messages.ru.yml
src/Events/Controller/
src/Events/Entity/
src/Events/Services/
src/Events/Resources/config/doctrine.yml
src/Events/Resources/config/services.yml
src/Events/Resources/translations/messages.ru.yml
tests/Blog/Entity/
tests/Blog/Services/
tests/Events/Entity/
tests/Events/Services/
templates/Blog/index.html.twig
templates/Blog/layout.html.twig
templates/Events/index.html.twig
templates/Events/layout.html.twig
templates/base.html.twig
templates/index.html.twig
templates/layout.html.twig

Меня такая структура проекта вполне устраивает. Вам решать, подходит она вам или нет.

Есть еще нюансы с DDD, но я думаю вам сейчас это не нужно.

Как делать пакеты как у Symfony?

Максим перенес комментарий

Как делать пакеты как у Symfony?

У меня есть опыт такого подхода.

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

Не думаю что у вас есть в это особая необходимость. Но вы можете разработать какие-то свои компоненты и вынести их в отдельные репозитории и устанавливать как зависимости. Можно даже сделать их open source и сообщество может вам помогать в их разработке и сопровождении.

Как и сказал BoShurik, бандл это уровень интеграции компанента в фрайморк. Выделяя компонент в отдельный репозиторий вам нужно и бандл выделять в отдельный репозиторий. Так у вас будет 2 отдельных git репозитория.

Таким образом у вас будет следующие git репозитоии:
- ядро проекта
- компонент блога
- бандл блога
- компонент мероприятий
- бандл мероприятий
- компонент деятелей
- бандл деятелей
- компонент аккаунта
- бандл аккаунта
и др. х2

Разделение проекта на много независимых репозиториев это не есть плохо. Как и разделение проекта на микросервисы. Но у этого подхода есть существенный недостаток. Часто нужно внедрять новые фичи или править баги которые требуют внесения изменений в несколько репозиториев одновременно. Это доставляет массу неудобств. Особенно когда нужно проходить через этап релиза. Протестировать в проекте работу правок можно только после внесения их в бандл и релизе его, а зарелизить бандл можно только после его тестирования, а тестирование бандла требует тестирования и релиза компонента, а делать релиз компонента не убедившись как оно будет работать в конечном продукте нельзя. В общем релизный ад. Я проходил через него и не советую другим. Это осмысленно только для больших проектов с большой командой разработчиков.

Как и сказал BoShurik, разделяйте проект на независимые модули и организуйте модули в папки и неймспейсы. Я пользуюсь этим методом уже несколько лет. Полет нормальный.

App/Blog/Controller
App/Blog/Entity
App/Events/Controller
App/Events/Entity

Разработчики Symfony зря советуют не использовать бандлы. Ваши модули по сути и будут бандлы. Вы создаёте в модуле бандл в котором описываете метод интеграции модуля с фреймворком.

App/Blog/AppBlogBundle
App/Events/AppEventsBundle

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

Стоит ли изучать Javascript до HTML и CSS?

Роман, а бекенд что отдает? Разве не HTML?
Для бекенда тоже необходимо базовое знание HTML. Разве что на NodeJS писать тулзы не относящиеся к веб, но тогда нет смысла в JS и надо брать нормальные языки.

Как отслеживать открытия писем?

Дмитрий Шицков, я не хочу прочитать письмо.
Я хочу знать когда пользователь сам прочитает письмо.
Прямого доступа к почтовому серверу нет.

Как быть с событиями из агрегата, который используется в агрегате уровнем выше?

Artem Moseev, Если Active Record, то да. Лучше сделать отдельный класс сущности.

А что у тебя Active Record делает с Doctrine? Или у тебя Yii?
Любопытно просто.

Как быть с событиями из агрегата, который используется в агрегате уровнем выше?

Artem Moseev, этим и хороша доктрина, что вы в сущности описываете только вашу бизнеслогику, а вся привязка сущности к БД реализуется через аннотации или вообще в отдельном файле конфигураций.

И сущность у вас чистая как слеза младенца и ничего не знает об окружении и делает только то, что должна в соответствии с бизнес требованиями.

Как быть с событиями из агрегата, который используется в агрегате уровнем выше?

А зачем их разделять? Это одна и та же сущность.
Класс User с методом buyService, это не сервис доменного уровня, а именно сущность.

Похоже сущность связанная с доктриной у вас является анемичной моделью.
https://habrahabr.ru/post/224879/

Какой фрэймворк выбрать Yii 2 или Symfony 2?

Антон Дышкант, если вам искренне интересно, то расскажу.

Начнем с того что 90% кода Yii 1 не читаемый говнокод. В Yii 2 они немножко подтянулись, но не значительно.

В Yii 1 IoC нет вообще. В Yii 2 его добавили, но реализация у него неправильная. В Symfony 3.3 например добавили автоконфигурирование сервисов и ты уже не думаешь о зависимостях, ты просто указываешь нужный тебе интерфейс в конструкторе или аргументе экшена. А все сервисы в приложении разом конфигурируются в 20 строк.

Как в Yii 1, так и в Yii 2, доступ к сервисам осуществляется через синглтон Yii::app(), что само по себе показывает на сколько Yii плох.

В Yii по умолчанию используется php шаблонизатор, что провоцирует ко всяким гадостям в шаблонах.
Конечно можно подключить twig, но суть в том, что то что по умолчанию там обычно и остаётся.

В Yii модели описываются как ActiveRecord, что тоже плохо для DDD. Проблема решается переходом на Doctrine.

На сколько я помню, в Yii нет поддержки переводов по умолчанию (могу ошибаться). В Symfony есть и есть бандл для перевода данных в БД.

В Yii нет нормального кеширования результатов работы экшенов в контроллерах.
В Symfony, за счёт того что это Request/Respons фраймворк, есть полный контроль над кешем.

Роутинг в аннотациях на мой взгляд удобнее чем файл с роутами, но это на любителя. В Symfony есть 3 способа описания роутов, в Yii только 1.

Касательно форматов. Мне нравится YAML. Он компактный, лаконичный и легко читаемый. Его в Yii явно не хватает.

Можно долго продолжать.
Конечно мы можем улучшить Yii компонентами из Symfony, но зачем нам тогда Yii? Может сразу взять Symfony?

Уж чем мне не нравится Laravel, но даже он лучше Yii.
Наверное потому что использует компоненты Symfony.

Подитожу.
Я знаю только 2 преимущество Yii перед Symfony, это:
- Yii в некоторых случаях быстрее Symfony хотя это спорно и на больших проектах может оказать медленнее Symfony.
- Yii легче для изучения новичкам в программировании, далёким от таких понятий как DDD

А вот говнокодить на Yii самое то.
Тяп ляп и в продакшн.

Если кто-то знает ещё преимущества Yii перед Symfony. Пожалуйста отпишитесь. Мне правда интересно.

Может Kir --- что-то знает?