Челендж на 2026

 Для этого существует Тильда. Для более продвинутых - Вордпресс. 

Не нужно. Те, кто не умеют программировать - вообще не должны знать про существование БД. Ты пытаешься завелосипедить то, что давно известно. Ты не сможешь написать суперпростую ОРМ, потому что не понимаешь до сих пор целевую аудиторию своего поделия.

сколько лет прошло? А ты все еще запрягаешь? Александр за 2 недели создал скелетон, который я без наличия  ПХП на компе смог запустить. А ты до сих пор даже не озадачился со скриптом установки. 

Я уже советовал тебе ознакомитсья с приниципами разработки ПО, может тогда бы ты сам увидел свои ошибки. Но ты думаешь что умнее всех...

Мой без вариантов. :) Поясню не спора для

Если сравнивать результаты челенджа, то тут вообще два абсолютно разных инструмента для разной ЦА. Их сравнивать не корректно. Но вот если конечной целю поставить: инструмент для неподготовленного человека, то тут все сильно иначе.

И тут как раз вся суть в понимании термина "фреймворк" (я не просто так хотел узнать твое видение этого)

В моем понимании. 

Фреймворк - инструмент для разработчиков. На нем надо программировать. Однако может быть на разной "глубине". т.е На примере ЯП% и чистый асм и джава вооруженная фреймоврками это все языки программирования, но вот количество кода для решения одной и той же задачи требуется разное. Так и здесь один фреймворк решает из коробки 1% задач, другой 80%. 

Далее CMS - в ее основе лежит фреймворк, но уже большое число функций можно решить не зная ни ЯП ни html/css. Т.е. если простой проект и подобрали правильно cms. То тут тоже может быть ни чего не придется учить. Просто уровень вполне достаточный: "пользователь CMS".   

Далее идет констуркторы сайтов. По сути та же CMS. Только тут уже больше все в режиме "наелозить мышкой по страничке и поотвечать на вопросы мастеров". Т.е это даже просто более продвинутый интерфейс CMS. :) Здесь пользователю вообще не надо знать ни о каких то бд, ни о каких то xml да даже css html не надо.

Т.е. потенциально мой проект закрывает вообще все варианты целевой аудитории.

Ну и конечно же у меня есть огромнейший плюс, я использую композер. А это значит, что пользователь моего фреймворка потенциально уже прямо сейчас может установить любые из 441 484 пакетов зарегистрированных на packagist (а можно ведь кроме этого и пакеты с github, но не зарегистрированные на packagist). Предположим даже там много аналогов,  пусть только треть "уникальны", чтобы воспроизвести этот функционал даже если в день по пакету успевать то это 402 года. А теперь взглянем на АПИ wildberries клиента для такого за день? :)  (а это сейчас нужно большинству интернет магазинов, а есть еще и другие МП)

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

По результатам болтовни на форуме немного усоверщенствовал свой анализатор. Теперь идет проверка не только математического совпадения, но и анализ через LLM  определенно выше. Пока работает через OpenAI только.

Градация ответов ллм от "Да, вероятно " до "нет", например "возможно" = это уже высокая степень совпадения

Ну чтож, очередная пятница и очередная тишина от "профессионала"... Похоже, за явным преимуществом досрочно победу можно присуждать Александру 💪

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

Ну справедливости для: все же челендж это не соревнование, а скорее оценивать можно будет по истечении года по достигнутому прогрессу. И, второе: "отчетная" неделя следующая.

ЗЫ У меня замедление (меньше свободного времени было), но тем не менее успел лексера аж три прототипа написать, выбрал окончательный, но для полноценного продолжения в фреймворке нужны окружение, конфиги, загрузка модулей. (на гихабе появилась ветка next) в общем в процессе.

Ну пока что от твоего конкурента не было ни одного отчета, сомневаюсь что и следующая "отчетная" неделя что-то исправит...  Годовой челлендж имеет смысл с регулярными отчетами, а не обещаниями. 

Кстати вот мне интересно, почему у тебя в гитхабе основная ветка - master? Руками переименовываешь? Уже давно стандарт - main. И ты не любишь gitflow? Заметил что ты всю разработку ведешь в основной ветке. Я предпочитаю так не делать. 

Еще - docker-compose  теперь не требует версии - устарело.

ИМХО, main - это стандарт  навеянной этой дебильной идеей про угнетение народов. Принципиально нет :) Завтра кто то пустит волну, что и "main" это оскорбление - опять перестраиваться под идиотов далеких от IT?  Лично мне master - понятнее и правильнее, в конце концов привычнее.

ну от чего же. Обычно в мастере только мелочи (ну типа в доке что то поправить), но всегда это завершенный этап. по коду - релиз. Далее уже что просачивается на github. Сейчас ветка next там идет просто разработка, веток,на самом деле пока нет, если что то пойдет в параллель естественно появится разделение по фичам, но не факт что на гитхаб все поедет, как правило в подобных случаях оно попадает в next и уже на гитхаб.  

Если про шаблонизатор, там нет еще стабильной ветки, нет релиза, потому все в мастере.  выпущу релиз - там тоже пойдет по веткам.

оке

main -  на две буквы короче, значит удобнее. )

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

Ну у меня не совсем "классическая" схема. Тому  ряд причин:

git использую даже на мелочах (для себя всякую мелочевку) - она вообще на github не бывает. Основные проекты Битрикс - там файлы могут быть изменены контент менеджером или СЕО шником (через интерфейс но все же) . Это тоже накладывает свое.  На большинстве проектов я один единственный разраб, и гита до меня не было. И там все без github и его аналогов.  (по сути на gitlab только есть рабочий проект один).  т.е. схема примерно такая: master - чистая ветка, все правки попадают на прод через hotfix.  Локально веду разработку в фьюча ветках, заливаю в hotfix, с боя в мастер принимаю все изменения, что там наколбасили все кому не лень, мержу в хотфикс с устранением конфликтов, далее на прод и там уже мержу в мастер. Да вроде как не правильно, но я привык :)  Пока не разбирался как по взрослому (опять же я ни когда не работал в больших командах с поставленным процессом). Если честно там где я один - не хочется запариваться с процессом и настраивать это все.  Тем более, может быть и такое: у меня один клиент попробовал другого разработчика, потом вернулся я "ремонтировать", одна из фишек от того разработчика: часть кода правилось от рута, и права 777  бахнуты.  :)

Короче "по привычке так". я даже как то у себя статью писал на эту тему. там правда уже давно ее надо подправить (и в битриксе важные изменения есть влияющие на это процесс, ну и я несколько подправил подход)..