Проблема в том, что как правило уже есть проект не на Amp/Swoole, но хочется внедрить для некоторых операций параллельщину. И вот тут начинаются проблемы с сериализацией. Т.к. огромное кол-во кода просто нельзя пропустить через тот же amphp/parallel, т.к. он не сериализуем (doctrine, symfony/http-client, ...).
Многие комментарии к данной статье отлично показывают, почему в пост-СССР такие проблемы с электроникой. Следствие разрухи в головах и непрекращающихся попыток вылизать сапоги белым заокеанским господам.
По-моему, всю отрасль пора "ператрахивать" и возвращать в инженерное русло.
по-моему, сообщество в php давно созрело для создания нормальной стандартной библиотеки, а не вот этой мешанины в глобальном неймспейсе.
так же очень полезны были бы нормальные структуры данных в ядре (https://github.com/php-ds/ext-ds).
судьба fiber-ов, и прочей асинхронщины по прежнему туманна. ведь влом stream прослойку переписывать, проще и забавнее протолкнуть очередной дурацкий сахар в синтаксис, а не заниматься реально нужными вещами.
Вот у меня тоже хабр где-то среди первых закладок, которые открываю.
Но, с мнением
Закрытое, токсичное комьюнити со своей атмосферой, где выдавливают инакомыслие, чморят новичков, и никого не принимают в свой клуб. Рассадник корпоративных блогов, которые занимаются переводами низкосортных материалов с американских технобложиков.
абсолютно согласен. Чтобы найти стоящую статью тебе придется перелопатить штук 50 полного г-на. И тенденция только ухудшается. Я не знаю альтернативы. opennet? там сисадминская тема, linux.org.ru? тоже + совсем своя атмосфера. а больше и не знаю русскоязычных ресурсов.
На хабр завезли помимо рекламного барахла еще очень много политоты с определенным уклоном и прочей максофилией.
1 — NULL/NOT NOT, unique, fk — это все не только бизнес логика, но и технические ограничения. Позволяющие лучше понять, как разработчику, так и СУБД как лучше (правильнее) работать с данными.
2 — Если у приложения несколько интерфейсов, то и бизнес требования на каждом из них могут отличаться. СУБД тут может выступать арбитром в принятии конечного решения, проходят ли данные или нет.
3 — Иногда данные таки приходится править через различные db viewer-ы, да или даже миграции, где ты их вносишь в обход валидаций уровня приложения. Те же foreign keys или unique таким образом можно легко нарушить.
4 — В целом, зачем тогда реляционная СУБД? Все скатывается в NoSQL и контроль данных на уровне приложения.
не могут. эти "ньюансы" пусть решает IDE. а забивать голову подобными "особенностями" полезно только разве что для собеседований с вопросами на бумажке на внимательность.
есть нормальный gitflic который реально наш. зачем каждая контора теперь пытается втюхать свой велосипед?
а когда нормальный процесс обновления без простоя сделается? mysql из коробки умеет.
https://www.php.net/manual/ru/intro.pcntl.php только для cgi/cli. что сильно ограничивает применение. https://stackoverflow.com/questions/35026153/call-to-undefined-function-pcntl-fork-php-fpm-nginx#answer-35029409 комментарий от Joe Watkins.
parallelпогиб - комментарий от тогоже Joe Watkins https://github.com/krakjoe/parallel/issues/201#issuecomment-892442141по факту нужно смотреть в сторону swoole/amphp
переход на голанги и ноды не имеет отношения к "высокой" квалификации. это лишь мода.
подробнее, например, тут https://github.com/amphp/ext-fiber/issues/9
пример неработающей связки amp и symfony/http-client - https://github.com/Gemorroj/parallel-nonserializable
Проблема в том, что как правило уже есть проект не на Amp/Swoole, но хочется внедрить для некоторых операций параллельщину. И вот тут начинаются проблемы с сериализацией. Т.к. огромное кол-во кода просто нельзя пропустить через тот же
amphp/parallel, т.к. он не сериализуем (doctrine, symfony/http-client, ...).Многие комментарии к данной статье отлично показывают, почему в пост-СССР такие проблемы с электроникой. Следствие разрухи в головах и непрекращающихся попыток вылизать сапоги белым заокеанским господам.
По-моему, всю отрасль пора "ператрахивать" и возвращать в инженерное русло.
del
ага, по ходу можно не просто алиасы запилить, а поправить консистентность. прям хочу.
Этот комментарий прекрасно показывает уровень местных "умных айтишников". Смесь запредельного чсв с таким же запредельным скудоумием.
Прям таки нужно, ага. Дурацкое копирование дурацких веяний.
попробовал, не понравилось. как будто на php 4 пишешь.
по-моему, сообщество в php давно созрело для создания нормальной стандартной библиотеки, а не вот этой мешанины в глобальном неймспейсе.
так же очень полезны были бы нормальные структуры данных в ядре (https://github.com/php-ds/ext-ds).
судьба fiber-ов, и прочей асинхронщины по прежнему туманна. ведь влом stream прослойку переписывать, проще и забавнее протолкнуть очередной дурацкий сахар в синтаксис, а не заниматься реально нужными вещами.
а где восстановление из дампа?
Вот у меня тоже хабр где-то среди первых закладок, которые открываю.
Но, с мнением
абсолютно согласен. Чтобы найти стоящую статью тебе придется перелопатить штук 50 полного г-на. И тенденция только ухудшается. Я не знаю альтернативы. opennet? там сисадминская тема, linux.org.ru? тоже + совсем своя атмосфера. а больше и не знаю русскоязычных ресурсов.
На хабр завезли помимо рекламного барахла еще очень много политоты с определенным уклоном и прочей максофилией.
не согласен. хабр тут собака, а не хвост.
https://3v4l.org/YaF6p
везде false
1 — NULL/NOT NOT, unique, fk — это все не только бизнес логика, но и технические ограничения. Позволяющие лучше понять, как разработчику, так и СУБД как лучше (правильнее) работать с данными.
2 — Если у приложения несколько интерфейсов, то и бизнес требования на каждом из них могут отличаться. СУБД тут может выступать арбитром в принятии конечного решения, проходят ли данные или нет.
3 — Иногда данные таки приходится править через различные db viewer-ы, да или даже миграции, где ты их вносишь в обход валидаций уровня приложения. Те же foreign keys или unique таким образом можно легко нарушить.
4 — В целом, зачем тогда реляционная СУБД? Все скатывается в NoSQL и контроль данных на уровне приложения.
По-моему, статья "Почему плохо надеяться на БД для валидации данных" — это из вредных советов.
не могут. эти "ньюансы" пусть решает IDE. а забивать голову подобными "особенностями" полезно только разве что для собеседований с вопросами на бумажке на внимательность.