Просто мысли в слух... Что если на тестовом сервере создать отдельные git worktree для каждого разраба, а девопс создаст отдельные сабдомены тестового сервера для каждого разраба и настроит их так, чтобы при обращении к ним сначала читались файлы из worktree соответствующего разраба, а если не найдены, то уже из папок сервера? Тогда у каждого разраба будет свое место для экспериментов. Так главный worktree будет всегда в нормальном состоянии, для тех, кто не хочет работать по вашей схеме.
Потому, что в Маке скролл-бар сделан поверх контента, а в Винде сбоку от контента. Постоянно вижу одну и ту же проблему у верстальщиков работающих на Маке: их верстка раздражающе дрыгается влево-вправо при открытии попапов в браузерах на Винде. Вот и вы об этой проблеме скорее всего тоже не знали.
Все равно смешение контента на ширину полосы прокрутки остаётся единственным надёжным решением. Только ширину полосы прокрутки нужно определять динамически и создавать соответствующий CSS-класс на лету, а не так как показано в этой статье - хардкодом. Ширина эта может быть разная, при разных масштабах страниц и интерфейса операционной системы. Я не раз уже убеждаюсь, что комитет по стандартизации CSS очень слабо понимает, какие проблемы возникают в вёрстке сложных сайтов с интерфейсами ну очень сильно отличными от сайта Википедии. Те же единицы dvw и dvh наконец ввели совсем недавно. До этого все модальные окна ещё и прыгали вертикально в мобильных браузерах при прокрутке. Web-у уже миллион лет... И до сих пор нет никакого вразумительного управления контентом с учётом разных вариантов и размеров прокруток, а также стилями прокруток и форм.
Когда в CSS только появились медиа-запросы, первой мыслью было, а почему нет контейнерных медиа-запросов, почему только с привязкой к viewport? Ведь с привязкой к размеру контейнера было бы намного логичнее и удобнее? Данный функционал появился только недавно, через 15 лет!
Свойство text-align со значениями start и end, поддерживается всеми браузерами примерно с 2013 года. А в основных браузерах оно появилось в период 2004-2008. Оно прекрасно знакомо всем, кто хоть раз собирал сайты на языках с ориентацией письма справа-налево.
Вы серьёзно определяете шрифт по его названию в 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-ом сильно упрощает процесс управления кодом проекта, независимо от количества программистов вовлечённых в проект.
"А там, как знать, может быть, лет через восемь в Васюках состоится первый в истории мироздания междупланетный ИИ-конгресс! <...> Из Васюков полетят сигналы на Марс, Юпитер и Нептун. Сообщение с Венерой сделается таким же лёгким, как переезд из Рыбинска в Ярославль. <...> Не беспокойтесь, — сказал Остап, — мой проект гарантирует вашему городу неслыханный расцвет производительных сил."
“Человечество не изменилось за последние две тысячи лет”, – сказал Воланд.
Просто мысли в слух... Что если на тестовом сервере создать отдельные git worktree для каждого разраба, а девопс создаст отдельные сабдомены тестового сервера для каждого разраба и настроит их так, чтобы при обращении к ним сначала читались файлы из worktree соответствующего разраба, а если не найдены, то уже из папок сервера? Тогда у каждого разраба будет свое место для экспериментов. Так главный worktree будет всегда в нормальном состоянии, для тех, кто не хочет работать по вашей схеме.
Как это не нужны случайные разговоры с посторонними? А как же:
— Вас там, поди, дождем залило?
— Там, это где — по-твоему?
— Ну судя по номерам, вы ехали из Далласа.
— А твое какое дело, дружок?
Потому, что в Маке скролл-бар сделан поверх контента, а в Винде сбоку от контента. Постоянно вижу одну и ту же проблему у верстальщиков работающих на Маке: их верстка раздражающе дрыгается влево-вправо при открытии попапов в браузерах на Винде. Вот и вы об этой проблеме скорее всего тоже не знали.
Все равно смешение контента на ширину полосы прокрутки остаётся единственным надёжным решением. Только ширину полосы прокрутки нужно определять динамически и создавать соответствующий CSS-класс на лету, а не так как показано в этой статье - хардкодом. Ширина эта может быть разная, при разных масштабах страниц и интерфейса операционной системы. Я не раз уже убеждаюсь, что комитет по стандартизации CSS очень слабо понимает, какие проблемы возникают в вёрстке сложных сайтов с интерфейсами ну очень сильно отличными от сайта Википедии. Те же единицы dvw и dvh наконец ввели совсем недавно. До этого все модальные окна ещё и прыгали вертикально в мобильных браузерах при прокрутке. Web-у уже миллион лет... И до сих пор нет никакого вразумительного управления контентом с учётом разных вариантов и размеров прокруток, а также стилями прокруток и форм.
Когда в CSS только появились медиа-запросы, первой мыслью было, а почему нет контейнерных медиа-запросов, почему только с привязкой к viewport? Ведь с привязкой к размеру контейнера было бы намного логичнее и удобнее? Данный функционал появился только недавно, через 15 лет!
Свойство text-align со значениями start и end, поддерживается всеми браузерами примерно с 2013 года. А в основных браузерах оно появилось в период 2004-2008. Оно прекрасно знакомо всем, кто хоть раз собирал сайты на языках с ориентацией письма справа-налево.
А Юнити могут попытаться, если снова наймут супер-мега-эффективного топ-менеджера, который выстрелит себе в ногу и будет уволен с позором.
Вы серьёзно определяете шрифт по его названию в 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 ИИ?