Российский центр компетенций по импортозамещению отказался инвестировать в два проекта на базе Java

Какие у него преимущества по сравнению с Typo3?

Никаких. Это самое ужасное из того что существует.

Бибиктрикс - самое ужасное? IMHO просто поехавшее …

Это вы ещё код магенто 2 не видели.

Вообще, CMS на PHP делается за рабочую неделю со всеми ACL, пагинацией и прочей CRUD админкой, это зачастую малая часть веб-проекта и никакие WP, Typo3 и прочие Codeignitor не используются.

Да я не против помочь отечеству, просто тейки оч тупые, скатиться от обсуждения потоконебезопасности в Java к CMS на PHP за пару постов обсуждения это кек.

нет хорошего фреймворка для работы с СУБД в джава

jooq весьма годный.

Вообще, CMS на PHP делается за рабочую неделю со всеми ACL, пагинацией и прочей CRUD админкой, это зачастую малая часть веб-проекта и никакие WP, Typo3 и прочие Codeignitor не используются.

Из готовых наработок или каждый раз с нуля? А все узкоспециализированные разработчики CMS тупые, и не могут осилить иной раз за 10 лет, постоянно что-то доделывают, багфиксят, улучшают.

А тут хоба, и за неделю, LOL

И абсолютно без ошибок, аналогично математически верифицированнному коду (который стоит около $200/1 LoC - Line of Code)?

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

С другой стороны, если это богатый клиент, и у него денег куры не клюют, то аналогично Go макакам, нужно заткнуть дыры, завозим ещё один трюм рабов и фперёд и с песней. (Я такой подход НЕ одобряю).

простой crud там тоже делать вполне себе просто

jooq весьма годный

Да, это уже ближе к тому, с чем бы хотелось работать. Но остаётся проблема с контролем данных. Дублирование кешей, схем и т.д. У нас СУБД отдельно, JVM отдельно. Я бы хотел их объединить в одну сущность. Может даже когда-нибудь осилю такой проект, если кто раньше не сделает.

Из готовых наработок или каждый раз с нуля?

Берётся фреймворк который соответствует PSR и на нем реально за неделю делается. А если с готовыми наработками то и за выходные.

А все узкоспециализированные разработчики CMS тупые, и не могут осилить иной раз за 10 лет, постоянно что-то доделывают, багфиксят, улучшают.

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

Я же говорю об узкоспециализированном варианте, например, когда разрабатывается апи сервер платёжных методов и методов доставки и для их добавления/управления и нужна CRUD админка. И т.д. Подключать для этого Typo3 не имеет никакого смысла.

Дублирование кешей, схем и т.д.

Да что ты такое, черт побери, несёшь? Какое дублирование, каких кешей?

Я бы хотел их объединить в одну сущность.

Зачем?

Может даже когда-нибудь осилю такой проект, если кто раньше не сделает.

Прилинковать к своему приложению какую-нибудь готовую недоСУБД на Java?

Как в InterSystem Cache, в ПФР затроение-запятерение данных, LOL

Я же говорю об узкоспециализированном варианте, например, когда разрабатывается апи сервер платёжных методов и методов доставки и для их добавления/управления и нужна CRUD админка. И т.д. Подключать для этого Typo3 не имеет никакого смысла.

Так наверно тоже есть что-то готовое.

Не поверю, что у вас при объёме кода хотя бы в 1K lines, написанных за неделю с нуля, не будет ни одной ошибки.

Так наверно тоже есть что-то готовое.

Да, Берётся готовый фреймворк, например Slim, а не CMS и пишется.

Не поверю, что у вас при объёме кода хотя бы в 1K lines, написанных за неделю с нуля, не будет ни одной ошибки.

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

Зачем?

Перечитайте внимательно ещё раз. Вон, даже Обезъянин возбудился, увидел знакомые буквы.

Прилинковать к своему приложению какую-нибудь готовую недоСУБД на Java?

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

Вон, даже Обезъянин возбудился, увидел знакомые буквы.

Не надо меня приплетать. Вы лоханулись на списке воркараундов в Java, потом на ереси про дублирование и сейчас хотите:

У нас СУБД отдельно, JVM отдельно. Я бы хотел их объединить в одну сущность.

Это что-то уровня джуна. Вы вообще не возбуждаете Обезьяна.

А можно пример на Github?

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

Заменить СУБД на алго работы с текстовым файлом, LOL ?

Кластер современной noSQL СУБД не справляется?

Вон, даже Обезъянин возбудился, увидел знакомые буквы.

Вам не страшно?

А можно пример на Github?

В 2014м году гитхаб вместе с прогрессивным западом выписал меня из людей и удалил все мои репозитарии вместе с кодом. С тех пор все мои решения только в закрытых рабочих репах. Могу посоветовать просто открыть Slim 4 документацию, скачать и попробовать, вы удивитесь насколько быстро и просто можно подключать middleware и писать свой код. Накидал роутинг, контроллеры и модели, подключил phinx для миграции БД, какой-нибудь шаблонизатор типа twig, для ORM сходу eloquent, в базовую модель CRUD, от неё наследование по сущностям и собсно все.

Может быть, чужой пример.

И ведь хостеров Git репозиториев типа Github довольно много разных.

а, и ещё, после этого сравните скорость получившегося решения с готовыми CMS, после чего готовые решения вы будете использовать примерно никогда.

Сомневаюсь, что прям сильно быстрее. А если правильно настроить кэширование и кластер с балансировкой, то тем более? IMHO время на разработку дороже, а уж тем более потом всякие баги и т.п.

И Typo3 - это ведь не специализированное e-commerce решение, а вот если nopCommerce или Virto Commerce.

Заменить СУБД на алго работы с текстовым файлом, LOL ?

С данными в текстовом файле, в некоторых случаях, можно быстрее работать, чем с доступом к ним через СУБД. Это так, вам на будущее.

Кластер современной noSQL СУБД не справляется?

Справляется, но PL/SQL придумали не просто так. Когда вы работаете в СУБД с данными на прямую это быстрее и проще. Но в моём случае вместо PL/SQL будет полноценная JVM, которая одновременно будет «современной noSQL СУБД» и бэкендом.

Может быть, чужой пример.

Можете поиском по Slim 4 skeleton найти варианты.

Сомневаюсь, что прям сильно быстрее.

А вы не верьте мне на слово, вы проверьте сами. Slim - один из самых быстрых PHP фреймворков на сегодняшний день.

С данными в текстовом файле, в некоторых случаях, можно быстрее работать, чем с доступом к ним через СУБД. Это так, вам на будущее.

Ога, особенно в многонодовой многопользовательской среде, а разработчики Redis, Tarantool и Clickhouse, даже и не знали …

Справляется, но PL/SQL придумали не просто так. Когда вы работаете в СУБД с данными на прямую это быстрее и проще.

Быстрее и проще? LOL

Вы видели код оптимизатора запросов, сортировок и т.п.?

Но в моём случае вместо PL/SQL будет полноценная JVM, которая одновременно будет «современной noSQL СУБД» и бэкендом.

Какая связь между PL/SQL и NO/SQL.

Говорили, мне в одном чатике, что на ЛОРе много поехавших, но от вас такого не ожидал …

Меня обычно скорость работы вообще не интересует (в пределах разумного конечно), только скорость разработки. Я никогда сам не разрабатывал high load проектов.

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

вот поэтому я и называю их java детьми, по суждениям их. Такая чистая и незамутненная ахинея.

Slim быстрый не только в работе, но и в разработке. Прочитайте PSR стандарты после чего бегло пройдитеcь по документации Slim и думаю вы довольно быстро сможете писать не приходя в сознание. Для средних проектов он также подходит.

Сомневаюсь, что PSR может так кардинально ускорить.

Вот XAF может, но он тут вообще не в тему, он для малых проектов со сложной моделью и навороченным GUI. Ускорение формошлепства в десятки раз, типа 1Це.

PSR это описание как делать правильно, Slim использует PSR, поэтому чтобы на нем писать быстро и легко стоит ознакомится как минимум с PSR 7 и PSR 11.

Писать никогда не будет быстрее и надежнее, чем деплоить готовое отлаженное годами (и иногда десятилетиями) :)

Вы так рассуждаете, как будто вам легче написать заново, даже если вы этот проект сохранили на флэшку, которую не можете найти за 10 минут.

Лень разжевывать. В ваших пэт проектах вам это не пригодится, так что не заморачивайтесь.

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

Считайте это high load контузией. Открываешь код magento 2, икаешь, закрываешь и качаешь Slim.

Ну есть же готовые распределённые кэши хотя бы типа Hazelcast?

https://hazelcast.com/products/#resources

Я еще могу согласиться, что обычные типовые CMS могут не подойти, но наверно есть специализированные решения или хотя бы можно сделать подобное на базе вашего типового, чтобы новые типовые клепались ещё в разы быстрее. И если уж у вас действительно там счет на миллисекунды, то наверно, что-то типовое из кастом обработчиков можно переписать даже на Rust или плюсах?

Дык разные части на разных языках и есть. Зачем например писать CRUD админку например, на Rust? Каждой задаче свой инструмент.

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

Проекты по 6-8 лет в среднем. На следующем проекте уже новый стандарт будет и возможности. Поэтому брать 1 в 1 не оправдано.

6-8 лет, а «накидать код приложения за неделю»?

Одно с другим как-то не очень стыкуется?

Вы начинаете передергивать, я говорил про конкретную часть - CRUD админку. Она пишется за неделю потом раз в месяц за час другой добавляются новые поля и тд, и так на протяжении жизни всего проекта. Весь проект пишется от 6 до 12 месяцев ударно и потом уже идёт доработка и сопровождение с учётом новых вызовов в реальной жизни.

Вы вроде и про Slim упоминали, а это ведь уже часть нагруженной части?

CRUD одной таблицы то и я могу на MS Access или LibreOffice base накидать за 5 минут. :)

Показания не сходятся :)

Вы вроде и про Slim упоминали, а это ведь уже часть нагруженной части?

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

CRUD одной таблицы то и я могу на MS Access или LibreOffice base накидать за 5 минут. :)

Именно так, просто на PHP в Slim вы этот CRUD заверните в Base модель, а потом каждый раз будете от неё наследоваться и определять поля таблицы в БД, а не писать CRUD в для каждой сущности с нуля.

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

Админкой и пользователи пользуются? Это типа личного кабинета?

Админкой и пользователи пользуются?

Она для внутреннего пользования сотрудников, из пары десятков варехаусов по всему миру пару сотен сотрудников дёргают разные части админку от CRUD форм до генерации qr кодов этикеток с внутренней инфой для товаров и тд.

Также, эту админку может через апи дёргать разные шлюзы, т. е. это не только сотрудники.

опять ничего не понял… что именно я не должен палить? Человек ввязался в дурно пахнущую дискуссию, наивно полагая, что обсуждаемые платформы можно хоть как-то сравнивать, а вместо хоть какой-то доли конструктива на него льют ушаты дерьма, я всего лишь пытаюсь «намекнуть», что «скриптота» как была дерьмом 20 лет назад, так таким дерьмом и осталась. Ну вот к примеру, код «рекламируемого» slim:

    public function __construct(LoggerInterface $logger)
    {
        $this->logger = $logger;
    }

    /**
     * @throws HttpNotFoundException
     * @throws HttpBadRequestException
     */
    public function __invoke(Request $request, Response $response, array $args): Response
    {
        $this->request = $request;
        $this->response = $response;
        $this->args = $args;

        try {
            return $this->action();
        } catch (DomainRecordNotFoundException $e) {
            throw new HttpNotFoundException($this->request, $e->getMessage());
        }
    }

    /**
     * @throws DomainRecordNotFoundException
     * @throws HttpBadRequestException
     */
    abstract protected function action(): Response;

или:

    protected function respond(): Response
    {
        $exception = $this->exception;
        $statusCode = 500;
        $error = new ActionError(
            ActionError::SERVER_ERROR,
            'An internal error has occurred while processing your request.'
        );

        if ($exception instanceof HttpException) {
            $statusCode = $exception->getCode();
            $error->setDescription($exception->getMessage());

            if ($exception instanceof HttpNotFoundException) {
                $error->setType(ActionError::RESOURCE_NOT_FOUND);
            } elseif ($exception instanceof HttpMethodNotAllowedException) {
                $error->setType(ActionError::NOT_ALLOWED);
            } elseif ($exception instanceof HttpUnauthorizedException) {
                $error->setType(ActionError::UNAUTHENTICATED);
            } elseif ($exception instanceof HttpForbiddenException) {
                $error->setType(ActionError::INSUFFICIENT_PRIVILEGES);
            } elseif ($exception instanceof HttpBadRequestException) {
                $error->setType(ActionError::BAD_REQUEST);
            } elseif ($exception instanceof HttpNotImplementedException) {
                $error->setType(ActionError::NOT_IMPLEMENTED);
            }
        }

        if (
            !($exception instanceof HttpException)
            && $exception instanceof Throwable
            && $this->displayErrorDetails
        ) {
            $error->setDescription($exception->getMessage());
        }

        $payload = new ActionPayload($statusCode, null, $error);
        $encodedPayload = json_encode($payload, JSON_PRETTY_PRINT);

        $response = $this->responseFactory->createResponse($statusCode);
        $response->getBody()->write($encodedPayload);

        return $response->withHeader('Content-Type', 'application/json');
    }

оно же только кажется что это ООП - ну вот, какие-то объекты есть, у них есть методы, их можно вызывать… нет, никаким ООП здесь даже и не пахнет (у меня есть голова - я в нее ем).