mechanic 48

Я не понял на какой комментарий Вы ответили, т.к. я не давал таких утверждений. Я написал, что ваш подход с проработкой бэкенда, который не видит потенциальный покупатель и халтурой во фронтенде в корне неверный если ориентируетесь именно на продажи. Но дело ваше и ваш кошелек. Хотите принимайте советы, хотите дальше воображайте, мне всё равно

Серьезно? Вы пишите блокировку транзакций, но аватар неважен, т.к. нет трафика? Если вы одиночка и продаете код, то как покупатель может оценить его? Вы же не оупенсорсный проект, код не видно? Ну вот я, как покупатель зашел и посмотрел. По работе сразу вопросы. По LLM я написал именно поэтому. Это типикал ошибка LLM. Она теряет контекст. У вас транзакции(пока трафика нет, серьезно заботитесь о блокировке транзакций?) проработаны, которых никто кроме вас и покупателей не увидит, но не проработана генерация условных аватарок, которая похерит всё при росте. Это будет бутылочным горлышком. Я вам уже раза три сказал про то, что сканирование дирректории с миллионом файлов аватарок, тем более в таком размере это непроработка архитектуры, которая при росте пользователей погубит проект, а не транзакция если ваше приложение не банковское. Я как покупатель посмотрел: Laravel - сразу средний хостинг. Шаред минус сразу. Посмотрел на портянки и загрузку на пустой странице в 2 секунды - сразу VPS с норм тарифом. Посмотрел раскрытие id без необходимости, все аватары в одной директории - при масштабировании придется всё переписать. На этом я как покупатель, который ознакомился именно с тем, что продают принимаю решение точно не брать. Если вы просто для продажи, тогда акценты перестройте. Покупателю не важны ваши транзакции, которые не видят сам код. Они оценивают то, что видят, а видят сомнительный интерфейс, как из под LLM, видят архитектурные проблемы, видят портянки и думают, что в серверной части такая же ерунда. Всё. Я понимаю, что вам важно продать, но вы, возможно, конфетку заворачиваете в обертку из г.на.

Такой код генерирует Claude opus 4.6.
Части написаны хорошо, но с оговоркой. Слишком мало кода, что бы давать оценку. По данным блокам да, видно опытного программиста. Но с такой типизацией как Block в замыкании? Используете все и сразу паттерны, которые используют в крупных проектах и по частям. Либо вы из FAANG, либо хорошо проработали инструкции для LLM. Я не понимаю, как вы, используя столько паттернов в гонке, делаете такие детские ошибки с теми же аватарами? Я задал вопрос: сейчас у вас аватары в таком виде: https://mediamix.codequadrum.com/storage/avatars/users/3_69a9f92ecd5c29.35670582_1772747054.jpg
Т.е. 1 директория на сколько? Если будет 20млн пользователей, то запрос будет сканировать 20млн файлов в одной директории? Для чего такой длинный хэш аватара? 10 стмволов - это 3.7 квадрилиона вариантов. у вас timestamp + id + хэш. Зачем в аватаре расскрываете id пользователя? в данном примере user id =3. Какая необходимость в этом? Это архитектурная ошибка. Открыли id просто так. Почему не используется конвертация в тот же webp? Если вы поддерживаете такие большие Аватарки, то почему не генерирует превьюшки 4848 или 6464? С таким кодом, который вы представили на транзакциях и такими детскими ошибками во вьюшке, я уверен, что код писал opus

Послушайте. Вы сейчас отвечаете как ЧатГПТ. Всё что перечислили это нативное в фреймворке. Покажите ваши классы, фасады, трейты. Если у вас включено кэширование, то такое время на генерацию это отсутствие оптимизации. На странице 3 поста. Всё. Если будет лента? Даже с асинхронной загрузкой на пустом сайте не должно быть такого. Используете VPS? Вот без пользователей с тремя демо акками у вас уже как высоконагруженное приложение работает. Вы пишите пост на ресурсе, который с комментариями, ссылками и прочим грузит в разы быстрее, чем ваше приложение без пользователей. Покажите часть кода если вы хотите устроить проверку своему приложению. Я вижу аватары 1024 пикселя, которые грузят в иконку размером 48пикселей. Ларавель мощный движок, но постоянный рендер и перезагрузка страниц при таком количестве js модулей, стилей. Поверьте, создатель фреймворка не может 100% оставлять свое мнение ко всем проектам. На вашем SPA обязательно. Без сингла это оверхед перезагружать такие страницы. И да, в таком случае vue.js, react. Либо смотрите на этот проект, поменяйте стек разработки. Посмотрите на количество подгружаемой архитектуры каждый раз при перезагрузке. Если вы тащите мегабайты стилей, то даже при кэшировании в браузере у вас на каждую перезагрузку страницы тянутся портянки стилей и кода. Нейминг аватаров в 16+ символов для чего? Такие даже в условном x.com не нужны. Не хватит пользователей на земле. + Всё в одной директории. Ну-ну. Когда будет миллион аватаров в одной директории? Я пишу с телефона и мне честно, не хочется чьи-то труды браковать, поэтому успеха вам, но он не Легаси и не для продакшн.

Не, там проблем море. Всё это посыпется однозначно. Прям вижу руку вайбкодера. Это генерка чистая. Там архитектуры ноль. Нейронка всегда на ларавель пишет, потому, что это самый полпулярный фреймворк. Но это для 80% сайтов бесполезный фреймворк потому, что 80% возможностей пользователь будет тащить за собой не используя их. Это мертвый код в легаси.

Если посмотреть сколько он тянет всего, то ясно, что на базовые потребности нужен уже средненький сервер и шаред хостинг не пойдет. С учетом нагрузки и роста числа пользователей, произойдет коллапс, т.к. в описании не вижу хотя бы базового кэширвоания. + nodejs сервер или чисто зависимости тянет, неясно. Это история для VPS с тарифом от 2000р в месяц минимум, прям на старт.

+ Просто беглый просмотр.

<div class="w-12 h-12 rounded-full overflow-hidden bg-gray-100 dark:bg-gray-700 shadow-sm ring-2 ring-gray-200/50 dark:ring-gray-600/50 group-hover:ring-brand-300/50 dark:group-hover:ring-brand-500/30 transition-all duration-300">
<img src="https://mediamix.codequadrum.com/storage/avatars/users/3_69a9f92ecd5c29.35670582_1772747054.jpg" alt="User" loading="lazy" class="w-full h-full object-cover">
</div> 

вот это тянет аватарку размером 1024x1024 px. Для чего? Нужен хотя бы crop или ресайзер, или хотя бы thumb версия. Ну и раскрытие id в нейминге аватара - такое себе решение. Этот пользователь имеет id=3. Подготовка к сбору данных для потенциальной атаки. Тем более раскрытие без необходимости. Портянки css и js можно решить кэшированием на клиенте, но все равно для такого ресурса это оверхед. Ну и использовать ларавель без vuejs странно. Это как антипаттерн. Прыгающий экран на таком стеке? Если тащить node, laravel то только one page реализация, тем более с такими показателями:

Запросы: 15/31
Перенесено 1.6 MB/1.6 MB
Ресурсы 119 B/2.1 MB
Завершено: 3.21 сек.
DOMContentLoaded: 1.65 сек.

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

Да, вот неясно. Сейчас в принципе стремная ситуация с персданными. Метрика - персданные, email персданные, рекаптча и авторизация через иностранные сервисы - трансграничная передача данных. Как в такой ситуации быть, понять не могу. Если установить Яндекс безопасность, то это не трансграничная, но все равно персданные. Но, хоть -1 проблема. Или опционально их сделать, либо то, либо то. Кто хостится не в стране, может в принципе игнорировать закон, поэтому якаптча для интернационального проекта не нужна

У меня вопрос. С мая 2025 года сильно ограничили использование иностранных сервисов. Либо регистрируешься, как оператор персданных, либо не должен собирать их. С Libarea есть email, google recaptcha. Кто использует систему, не приходят уведомления? Для физлиц вроде до 10т.р. штраф, но всё же

По совместимости — как быть со сторонними библиотеками? Там все классы.
Главное не мутировать их, а так, использовать. Почему нет? Да, это не чистое ФП, но упростить разработку если классные библиотеки стоит того. В целом, мы же не на haskell кодим в конце концов. Но, я именно не против классов, а против парадигмы ООП и принципов SOLID в ООП. Но, судя по вашим ответам, в коммерческой разработке всё как было 7-8 лет назад.

Для интерпрайз такой подход невыгоден (и еще по многим причинам)

Я думал в ентерпрайзе всегда самописы. Laravel - для 80% проектов избыточен. Покажите мне хотя бы один проект, где Лара уместна. В крайнем случае CI4.

И еще такой вопрос, насчет состояния. Вот есть данные запроса и данные пользователя. В каком виде это будет кочевать по функциям? В виде массивов?

Данные все в БД, будь-то Редис, Мускул, или Постгрес.

Но тогда как мы отличим массив с данными пользователя от какого-либо другого? Возрастает вероятность ошибки

Честно, немного не понимаю по поводу данных. Делаем запрос через функцию к БД. Получаем массив данных. Присваиваем его переменной. Всё. В переменной данные пользователя либо пустой массив. Далее через функцию структурируем или сортируем, разделяем. Зачем данным пользователя или приложения кочевать по приложению? Получили, обработали, вернули. Основной принцип ФП это получить данные, обработать, вернуть данные, без побочек. Строгую типизацию задаем в файле declare(strict_types=1); функции явные без побочек, например function getSessionValue(array $session, string $key, $default = null) { return array_key_exists($key, $session) ? $session[$key] : $default; }

По автозагрузчику функций тоже нет ясности, где писать require, который загружает необходимую функцию для другой функции? В этом же файле? Тогда это будет require_once во избежание конфликтов, который не особо хорош для производительности. Да и вообще разделение на большее количество файлов проблемно для производительности в целом.

require_once и require особо не заметите разницу при подключении, даже десятка файлов. Но, если подключите 2 одинаковых файла через require, то получите ошибку redeclare по функциям, что прямо укажет на ужеподключенный файл. Так же через spl_autoload_register можете подключать группу файлов с namespace к примеру. определили логически функции в директории src/users/notify, message, profile к примеру и через автозагрузчик коннектите группу файлов с namespace Users; Всё. Используете методы. Но опять же, прелесть в тонкости. При автолоадере классов вы тяните все, даже те, которые не используете. Например класс сессий или коннекта к БД, хотя страницы статичны. Зачем? Это как на странице без интерактива использовать vuejs.
Про большое количество файлов - это как раз к ООП вопросы и в частности к SOLID. Там класс одно действие. Если есть к примеру фильтры для одной группы товаров, то каждый фильтр для числовых значений, для строк, для массивов рекомендуется в разные классы через наследование и абстракции используем. Там то, что в несколько точечных функций можем уложить, раскидываем по сетке классов с приватными аргументами, методами и прочим. А после юнит тесты попробуй написать еще и где упадет найди после

Это добивается путем согласованности. Например все публичные функции пишем в snakecase или camelCase, а вспомогательные с _ или другим префиксом. Согласовать со всеми командами более чем легко, написав небольшой readme.md, тем более во многих языках написание определяет многое, как CONSTANT, $_SERVER и прочие синтаксические конструкции. Ну и следовательно такую функцию можно вызвать только преднамеренно. И логично, если разработчик подключает файл группы функций, то он осознано будет использовать его, что прямо не гарантировано при автозагрузчике классов

+ Если есть наглядный пример из прода, напишите его, где классы решают проблему, которую не решают функции.
Я просто наоборот, не вижу преимущества классов. Всё сообщество разработчиков вроде за строгую типизацию, но в тоже время используют мутабельность. Как такое возможно? Типа метод должен возвращать всегда int, но создав экземпляр класса можно его переиспользовать не для dogs, а для cats? Конечно, пример так чебе, но смысл его ясен вероятно

+ Если функции в одном пространстве имен, то с аналогичным названием функции, будут в другом пространстве имен. Если же функции по сути своей совпадают, то их можно использовать в новом файле пространства имен без переопределения класса или абстракций. Мне кажется это более прозрачно. Так же тесты легче проводить в виду изолированности групп функций. т.е. 1 файл - 1 тест. без зависимостей, без вложенности и мутабельности. Всё явно и просто для отладки. А как с тестами в дочерних классах? Что бы оттестить класс, надо размотать всю цепочку? И даже размотав нельзя поправить, т.к. базовый класс может похерить все наследования, абстракции и экземпляры, которые отличаются от базового(что логично).

Предлагается выше, что один файл — одна функция
Где предполагается? 1 файл - набор функций определенной группы с указанным namespace.
Ввиду отсутствия мутабельности и наследования нет мондража при оптимизации или обновлении файла под условно новую версию PHP. В случае с ООП придется проверить всех наследников, либо экстраполировать, создавая новые наследования и в них вносить изменения, что может привести к пропорциональному росту проекта, где первыце классы будут устаревать без изменений, но не смогут выбыть ввиду зависимостей наследователей. Так же, кто мешает создать автозагрузчик файлов определенных групп через splautoloadregister и далее использовать config\database();?

Я на LibArea начал изучать PHP т.к. мне надо было сделать проект этот именно на PHP.

Так она так же написана в парадигме ООП). Ну, по большей части. Я пытался написать небольшой проект, который в процедурном стиле занял бы 5мб кода, в ООП занимает более 15 + проект не завершен. Отладка, тесты, инкапсуляция, абстракции и прочие паттерны приводят к тому, что казалось бы простой код разрастается на 20 файлов и где именно происходит падение становится сложно отследить. В то время когда при процедурном подходе всё четко и ясно. Есть строка, есть ошибка. Код выпролняется сверху вниз. Тестами покрыл и наслаждаешься. Посмотрел все более менее популярные движки, по типу DLE, InstantCMS, Magenta, Wordpress там в целом смешанный подход. Используют процедурку с элементами ООП. Вот мне и стало интересно, сообщество разработчиков усложняет написание кода, т.к. кодовая база увеличивается в несколько раз, а следовательно и оплата растет пропорционально, или действительно такая проблема? Я не беру сейчас в пример энтерпрайз проекты с сотнями разработчиков и десятками микросервисов. Там каждый сервис на своем языке могут писать. Я в целом про 80% веба и систем на PHP

+ Подытожу. Я считаю преднамеренными действиями сообщества программистов для увеличения кодовой базы и, соответсвенно стоимости оплаты. Всё это подано под соусом удобства разработки командами, повторным переиспользованием и вот этим вот всем, но что мешает набор функций распределять по разным файлам с четким названием? Да и мультиинструмент всегда хуже узкоспециализированного. переиспользовать код, а после внесения правок в класс, при необходимости, обрушить систему, т.к. забыл где и когда переиспользовал метод класса или сам класс, или команда других разработчиков наследовала твой класс и написала своего динозавра - такое себе. По мне есть четкая функция и она выполняет только определенные действия. Меняя её четко понимаешь, что везде логика срабатывания едина и изменения её не принесут неожиданного результата

Последние прочитанные статьи подтверждают обратное. Даже этот проект придерживается ООП, хотя его можно уместить в сотню функций. Те же codecanyon сплошь и рядом завалены Laravel проектами, хотя по сути возможности фреймворка избыточны для них.

Сделал небольшое обновление.
Добавил немного визуальных улучшений: фон теперь с градиентом, модули тоже получили скругления и плавные переходы. Появились дополнительные SVG-элементы. Теперь можно выбрать размер экспортируемого кода - до 4000 пикселей.
Также улучшил скорость работы и генерации. Обновил сканер - фон больше не мешает распознаванию.
Если будет время, попробуйте сервис и напишите, что думаете. Любая обратная связь для меня очень важна.

На сервере еще редирект настроить надо с http:// Постоянно попадаю на 401 ошибку при авторизации)