Челендж на 2026

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

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

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

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

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

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

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

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

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

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

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

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

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

оке

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

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

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

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

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

В общем на гитхаб "рабочие" ветки крайне редко залетают,  в плане проекта с фреймворком - все мержи локально

А можешь рассказать свой флоу? Я даже свои проекты всегда веду в дев-ветке, обычно именую ее по названию фичи. Она тоже всегда в рабочем состоянии. Если есть желание - раскатываю дев-энв на хостинге(редко) После того как протестирую - создаю пулл-реквест на гитхабе. После ревью и аппрува - на гитхабе мержу в мэйн и он уже автоматически релизится и раскатывается на сервере. Сервер настраиваю обычно с помощью terraform, деплоить предпочитаю  через докер-контейнеры. То есть локально собирается готовый docker image. Потом он с помощью CodeBuild и AWS Pipeline раскатывается на сервере. С обычными хостингами уже лет 5 как не имею дел, только облака.

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