Вы серьёзно определяете шрифт по его названию в CSS? Без загрузки файла шрифта и чтения его мета-данных? Отличный план! Надёжный, как швейцарские часы.
Если скачать исходники Perl и скомпилировать, то в при компиляции будет создана miniperl - облегченная версия интерпретатора Perl. Сама она используется для дальнейшей сборки Perl. Это всего один исполняемый файл, который весит всего пару мегабайт!
Если компилировать в Windows с помощью древнего Windows Server 2003 R2 SDK, то получите файл miniperl.exe, который будет слинкован с древней версией msvcrt.dll и будет работать в любой версии Windows, начиная с XP без всяких дополнительных runtime библиотек.
Так вот, в миниперл можно пользоваться всеми возможностями языка, в нем нет только самих библиотек Perl. Сохраняется возможность работы с файловой системой, загрузка и обработка файлов регулярными выражениями, работа со стандартными потоками, базовая математика, запуск скриптов Perl без зависимостей от стандартных библиотек.
Удобно использовать как переносимый швейцаский нож для генерации кода, ресурсов, обработки текстовых файлов (напимер логов), скриптов для голого железа, систем востановления и т.д.
В вашем локальном API вы можете делать как угодно, если для вас это достаточно. Васянить можно как угодно. Но! Строго говоря, в общем смысле, API не может просто взять и поменять протокол. HTTP-коды не должны использоваться для бизнес-логики (хоть они ее частично и содержат). Эти коды используются для балансировщиков и маршрутизации запросов в сложных системах, чтобы им не приходилось каждый раз декодировать ваш payload и знать вашу бизнес-логику. А вот ваша чистая бизнес-логика должна быть полностью реализована на кодах ошибок и не должна анализировать для этого HTTP-коды.
Вот вы говорите: «Git держит все эти ваши копии проекта и итерации в одной базе данных». В какой?
В файловой базе данных Git у вас локально в папке проекта, или на сервере (если захотите), или на GitHub, или на Луне. Вы можете экспериментировать с какой угодно струтурой, с любым стилем кода, пишите хоть как курица лапой... Git вообще не про это.
В том же VS C++ как нужно устанавливать взаимодействие с Гитом? А в Питоне, особенно, когда я не использую никакие IDE для него? Как там с компиляцией и запуском на выполнение?
Складывается впечатление, что вы не очень то и понимаете, что это за инструмент. С подавляющим большинством IDE Git уже давно интергирован. А если не используете IDE, нет проблем... Всю историю проекта смотрите в каком-нибудь Git-GUI. Оттуда же управляйте, переключайтесь, откатывайтесь куда угодно...
Это уже не просто версии, откаты и «накаты», это постоянные изменения всей структуры проекта. Поможет ли мне здесь Гит?
НА ВСЕ 100! Вы в любой момент будете видеть всю историю кода, как вы его писали, где делали откаты, что меняли, где и когда, как было раньше, как стало теперь..., одной кнопкой можете исправить старый баг в одном месте и фикс магически прилетит во ваши итерации и под-проекты.
Справедливости ради следует сказать, чтобы изучить всю концепцию Git, и правильно пользоваться им, требуется довольно много времени, хотя делать базовые вещи навички сумеют уже через неделю в каком-нибудь Git-GUI.
... но у меня и так нет сложностей в «процессе управления кодом проекта». Все отлично управляется и без Гита!
Когда-то, когда я был зеленый - тоже так думал... Осознание приходит опытом. Но если вас все устраивает, изучать конечно нет смысла.
Это просто неудобно. Для вас это удобно, потому, что вы привыкли к своему велосипеду. Git держит все эти ваши копии проекта и итерации в одной базе данных, и в одной рабочей директории. В ней вы сами документируете все изменения. В любой момент можете откатиться назад, посмотреть как работало, вернуться вперёд. Можете вести несколько экспериментов или итераций паралельно, и затем код объединить. И ещё много чего можно. Самая большая ошибка - предполагать, что Git нужен исключительно для совместной разработки. Профессиональное владение Git-ом сильно упрощает процесс управления кодом проекта, независимо от количества программистов вовлечённых в проект.
"А там, как знать, может быть, лет через восемь в Васюках состоится первый в истории мироздания междупланетный ИИ-конгресс! <...> Из Васюков полетят сигналы на Марс, Юпитер и Нептун. Сообщение с Венерой сделается таким же лёгким, как переезд из Рыбинска в Ярославль. <...> Не беспокойтесь, — сказал Остап, — мой проект гарантирует вашему городу неслыханный расцвет производительных сил."
“Человечество не изменилось за последние две тысячи лет”, – сказал Воланд.
Вы серьёзно определяете шрифт по его названию в CSS? Без загрузки файла шрифта и чтения его мета-данных? Отличный план! Надёжный, как швейцарские часы.
Добавьте немного клея. Смешайте примерно 1/8 часть стакана клея с соусом. Нетоксичный клей подойдёт... Ой простите... Это был рецепт пиццы.
Если скачать исходники Perl и скомпилировать, то в при компиляции будет создана miniperl - облегченная версия интерпретатора Perl. Сама она используется для дальнейшей сборки Perl. Это всего один исполняемый файл, который весит всего пару мегабайт!
Если компилировать в Windows с помощью древнего Windows Server 2003 R2 SDK, то получите файл miniperl.exe, который будет слинкован с древней версией msvcrt.dll и будет работать в любой версии Windows, начиная с XP без всяких дополнительных runtime библиотек.
Так вот, в миниперл можно пользоваться всеми возможностями языка, в нем нет только самих библиотек Perl. Сохраняется возможность работы с файловой системой, загрузка и обработка файлов регулярными выражениями, работа со стандартными потоками, базовая математика, запуск скриптов Perl без зависимостей от стандартных библиотек.
Удобно использовать как переносимый швейцаский нож для генерации кода, ресурсов, обработки текстовых файлов (напимер логов), скриптов для голого железа, систем востановления и т.д.
В вашем локальном API вы можете делать как угодно, если для вас это достаточно. Васянить можно как угодно. Но! Строго говоря, в общем смысле, API не может просто взять и поменять протокол. HTTP-коды не должны использоваться для бизнес-логики (хоть они ее частично и содержат). Эти коды используются для балансировщиков и маршрутизации запросов в сложных системах, чтобы им не приходилось каждый раз декодировать ваш payload и знать вашу бизнес-логику. А вот ваша чистая бизнес-логика должна быть полностью реализована на кодах ошибок и не должна анализировать для этого HTTP-коды.
В файловой базе данных Git у вас локально в папке проекта, или на сервере (если захотите), или на GitHub, или на Луне. Вы можете экспериментировать с какой угодно струтурой, с любым стилем кода, пишите хоть как курица лапой... Git вообще не про это.
Складывается впечатление, что вы не очень то и понимаете, что это за инструмент. С подавляющим большинством IDE Git уже давно интергирован. А если не используете IDE, нет проблем... Всю историю проекта смотрите в каком-нибудь Git-GUI. Оттуда же управляйте, переключайтесь, откатывайтесь куда угодно...
НА ВСЕ 100! Вы в любой момент будете видеть всю историю кода, как вы его писали, где делали откаты, что меняли, где и когда, как было раньше, как стало теперь..., одной кнопкой можете исправить старый баг в одном месте и фикс магически прилетит во ваши итерации и под-проекты.
Справедливости ради следует сказать, чтобы изучить всю концепцию Git, и правильно пользоваться им, требуется довольно много времени, хотя делать базовые вещи навички сумеют уже через неделю в каком-нибудь Git-GUI.
Когда-то, когда я был зеленый - тоже так думал... Осознание приходит опытом. Но если вас все устраивает, изучать конечно нет смысла.
Это просто неудобно. Для вас это удобно, потому, что вы привыкли к своему велосипеду. Git держит все эти ваши копии проекта и итерации в одной базе данных, и в одной рабочей директории. В ней вы сами документируете все изменения. В любой момент можете откатиться назад, посмотреть как работало, вернуться вперёд. Можете вести несколько экспериментов или итераций паралельно, и затем код объединить. И ещё много чего можно. Самая большая ошибка - предполагать, что Git нужен исключительно для совместной разработки. Профессиональное владение Git-ом сильно упрощает процесс управления кодом проекта, независимо от количества программистов вовлечённых в проект.
Ну, он же сеньор-вайбкодер...
"А там, как знать, может быть, лет через восемь в Васюках состоится первый в истории мироздания междупланетный ИИ-конгресс! <...> Из Васюков полетят сигналы на Марс, Юпитер и Нептун. Сообщение с Венерой сделается таким же лёгким, как переезд из Рыбинска в Ярославль. <...> Не беспокойтесь, — сказал Остап, — мой проект гарантирует вашему городу неслыханный расцвет производительных сил."
“Человечество не изменилось за последние две тысячи лет”, – сказал Воланд.
Ну а что вы хотели, если Microsoft 365 Copilot ИИ-помощник на 50% написан с помощью Microsoft 365 Copilot ИИ?