Вы пишете, что компании других стран успешно переняли идеи Lean production, что помогло им выиграть ценовую конкуренцию. Из этого не следует, что идеи были плохими, скорее наоборот.
Но из-за того, что многие там продолжили фокусироваться на этой локальной оптимальности, они начинали вредить своему маркетингу и сервису. Или как минимум - не помогать.
Пример про экономику Японии кажется надуманным. Рецессия там началась еще в 1990 году, но какое отношение к этому имеет Lean production непонятно от слова совсем. https://en.wikipedia.org/wiki/Lost_Decades
union в С++ - это удобный инструмент для отстрела конечностей, своих и чужих. В то время как struct - это тот же класс, но с более удобными модификаторами доступа по умолчанию. struct практичен, позволяет писать более короткий и ясный код. Минус у него один - находятся эстеты, которым нравится писать слово "class", а "struct" их коробит по причинам зачастую не вполне рациональным.
Золотые деньги тоже подвержены инфляции, потому что новое золото добывается в рудниках, а товаров от этого процесса больше не становится. После открытия Америки в Европу хлынуло награбленное золото из колоний, что привело к росту цен в "реальных" деньгах. https://ru.wikipedia.org/wiki/Революция_цен
Cложности в таком сценарии вызваны не способом хранения кода, а тем, что 2 проекта долгое время живут независимо друг от друга, код в них сильно расходится, что приводит к большому числу конфликтов. Если оба проекта в итоге будут мержить свой код в основную ветку, то конфликтов не избежать в любом случае, независимо от способа организации кода. Полирепа лишь позволит в каких-то репозиториях этот процесс немного отложить за счет технического долга. Одно из возможных решений тут - не заводить долгоживущих веток. Примерно так: 1. Вливать изменения в основную ветку как можно чаще: дробить коммиты, не накапливать тысячи строк изменений. Бонус - небольшие пулл-реквесты проще ревьювить. 2. Нужен CI, который соберет код и в идеале еще запустит тесты и позволит убедиться, что сервисы во втором проекте не ломаются от изменений в первом. Наличие такого CI дополнительно мотивирует выкладывать код в основную ветку чаще. 3. При необходимости стоит прятать новые фичи под флаги. В качестве бонуса эти флаги потом в A/B тестах можно использовать. 4. Релизить сервисы чаще, не копить изменения месяцами/годами. Проблему разрешения конфликтов в коде все эти меры не решают, но позволяют уменьшить число конфликтов, цену ошибки и т.д.
Переход на версию +1 библиотеки 1 тянет за собой переход на версию +5 библиотеки 2
В монорепе по-хорошему все зависимости должны храниться в самой монорепе. Версионирования библиотек как такового нет, потому что всегда используется та версия, которая закоммичена в текущей ревизии.
Изначально речь шла об организации кода, разрабатываемого внутри компании - хранить ли его в одном большом монорепозитории или в множестве маленьких - полирепозитории. Мой пример относился к сценарию, когда нужно внести изменения в несколько разных частей в кодовой базы - библиотеки, микросервисы, какие-то тулы и т.п. Допустим, мне в рамках работы над проектом надо внести изменения в код 1 сервиса и 2 библиотек, от которых сервис зависит. Если все это хранится в разных репозиториях, то нужно сделать 3 пулл-реквеста. Разве не так? В монорепозитории я могу обойтись 1 пулл-реквестом. В фейсбучной монорепе, о которой пишется в статье, это мог бы быть стек коммитов (диффов), связанных с друг другом. Такой стек можно к примеру поребейзить относительно более свежей ревизии монорепозитория одной командой. В полирепозитории в каждом подрепозитории ребейз (или мердж) нужно делать отдельно.
Ветки можно создавать в любом репозитории: и в моно-, и в поли-. Вот только в полирепе это будет N веток по числу реп, с которыми приходится работать. Не понял ваш комментарий про "ничего лишнего не прилетело". В системе контроля версий вы всегда сами выбираете, какую ревизию счекаутить. Если вы имеете в виду процесс синхронизации долгоживущей ветки с основной, то в полирепе у вас будут те же самые проблемы с мердж-конфликтами. Рано или поздно все ветки придется вмерджить в master/trunk/main etc. После того, как все изменения закоммичены в ветки, все это добро нужно будет отправить на CI и code review. И тут снова вместо одного пулл-реквеста у вас будет N пулл-реквестов. Внутри CI ваш код будет запускаться с другими версиями соседних репозиториев, т.к. в соседних репозиториях пулл-реквесты еще не вмерджены в основную ветку. Соответственно, в разработке это придется учитывать, какие-нибудь флаги и условия расставить. Либо просто забить на CI и мерджить как есть.
Как систему не докомпозируй, а все равно на практике бывает нужно потестить изменения сразу в нескольких репозиториях (или директориях в случае монорепы). И тут монорепа гораздо удобнее. Для удобной работы с коллекцией репозиториев можно накрутить тулинг (например, как в Хромиуме), но в это нужно вкладываться.
Тем не менее бумажки, называемые рублями, в СССР были. Автоматизированную компьютерная система учёта и распределения всего производимого человечеством - это что-то из области фантастики. Хотя бы потому что эта система предполагает единые для всей планеты правила ведения этого самого учета. Сомневаюсь, что человечество способно о таком договориться. Ну и если представить что такая система есть, то там все равно внутри будет какой-то аналог денег для учёта ценности "всего производимого человечеством".
Идеальное общество, как вы его описываете, невозможно. Потому что люди в большинстве своем стараются действовать в своих интересах, которые не всегда коррелируют с интересами общества и его порядками. От соблазна получить что-то за счет окружающих никуда не деться. Кто-то может с этим бороться, а кто-то - нет. А еще к этому можно добавить обычную глупость. Идеальных людей не бывает.
Проблема в том, что бартер и прочие безденежные схемы не масштабируются. Поэтому ваш очень простой пример с домами на практике может работать, а вот с космическими программами так уже не выйдет. Даже в СССР в плановой экономике были деньги, потому что нужна мера оценки вклада каждого участника в экономику.
Ну а как в описанную вами схему вписывается запуск Вояджера? Эти же самые люди, будучи мастерами на все руки, будут еще и Вояджеры запускать из той же самой глины? На практике кирпичи, дома и Вояджеры строят специально обученные люди, а деньги это средство взаимозачетов между этими людьми.
Рейтинг Гитхат смещен в сторону опен-сорса. А на Фортране скорее всего написано много легаси-кода, который никто выкладывать в опен-сорс не торопится. Рейтинг популярности на уровне vim script - это как-то не серьезно.
А где тут запланированное устаревание? И ОС (Win 7), и браузер (Chrome) перестали обновлять, старые версии продолжают работать и будут работать еще долго. В случае с браузером так еще и исходники доступны. Автор поста просто развлекается, никаких дизассемблеров тут не нужно. В проекте Chromium есть удобный поиск по коду. Там все эти неподдерживаемые вызову Windows 7 можно найти. К примеру - ProcessPrng. Более того, автору поста еще в прошлом посте посоветовали форк Supermium, в котором обещают поддерживать аж Windows XP. Достойной формой протеста было бы участие в проекте Supermium. Если не кодом, то хоть багрепортами. Это деятельность была бы конструктивной. Вместо этого автор сагрился на человека, который имел неосторожность представиться сотрудником Гугла.
Я согласен с автором оригинальной статьи, что левый код читается лучше, т.к. фрагмент кода небольшой, все умещается на одном экране. Однако код в камне не высекается и имеет свойство со временем меняться. Если не меняется, то скорее всего этот код никому не нужен и читабельность его может быть какой угодно, т.к. никто его читать не будет. Если же код живой, то вариант слева со временем может вырасти в нечто нечитаемое строк на 1000, а то и более. Первоначальные авторы кода могут со временем уйти в другие проекты/компании etc. Приходят какие-нибудь стажеры. Или просто люди, которым надо по-быстрому запилить фичу здесь и сейчас. Код справа более устойчив к хаотичным правкам, его читабельность со временем будет деградировать медленнее.
Эх, эту бы статью да год назад :) Мы у себя накрутили обвязку вокруг jit.p профайлера. Он в целом хорош, если нет острой необходимости провязывать стеки С/С++ с Lua. Правда, в многопоточной среде нужно быть аккуратным. К примеру, вот тут в зависимости от дефайнов сборки может не оказаться мьютекса: https://github.com/LuaJIT/LuaJIT/blob/v2.1/src/lj_profile.c#L29
Дак там эмулятор на эмуляторе. То, что оно просто запустилось - это уже чудо. На вряд ли кто-то портировал код с x86 на ARM M1, т.к. исходники игр закрыты. Соответственно, запускается оно скорее всего под Розеттой, которая хоть и быстра, но нативному коду, конечно, уступает. Т.е. какое-то количество FPS на этом теряется. Далее сам код заточен под DirectX, который запускается через очередную прослойку над нативным Metal. И тут тоже без потерь FPS не обойтись.
Помимо этого, какие-то системные вызовы WinAPI могут неоптимально эмулироваться в Wine. Так же как в WSL 1.0 тормозили некоторые сисколы
Вы пишете, что компании других стран успешно переняли идеи Lean production, что помогло им выиграть ценовую конкуренцию. Из этого не следует, что идеи были плохими, скорее наоборот.
Тут примеров не хватает
Пример про экономику Японии кажется надуманным. Рецессия там началась еще в 1990 году, но какое отношение к этому имеет Lean production непонятно от слова совсем.
https://en.wikipedia.org/wiki/Lost_Decades
union в С++ - это удобный инструмент для отстрела конечностей, своих и чужих. В то время как struct - это тот же класс, но с более удобными модификаторами доступа по умолчанию. struct практичен, позволяет писать более короткий и ясный код. Минус у него один - находятся эстеты, которым нравится писать слово "class", а "struct" их коробит по причинам зачастую не вполне рациональным.
Непонятно почему они не вложат хотя бы часть этих денег в Мекку - инфраструктуру, жилье, транспорт и пр. Так могли бы и деньги отбить с паломников.
Золотые деньги тоже подвержены инфляции, потому что новое золото добывается в рудниках, а товаров от этого процесса больше не становится. После открытия Америки в Европу хлынуло награбленное золото из колоний, что привело к росту цен в "реальных" деньгах.
https://ru.wikipedia.org/wiki/Революция_цен
Cложности в таком сценарии вызваны не способом хранения кода, а тем, что 2 проекта долгое время живут независимо друг от друга, код в них сильно расходится, что приводит к большому числу конфликтов. Если оба проекта в итоге будут мержить свой код в основную ветку, то конфликтов не избежать в любом случае, независимо от способа организации кода. Полирепа лишь позволит в каких-то репозиториях этот процесс немного отложить за счет технического долга.
Одно из возможных решений тут - не заводить долгоживущих веток. Примерно так:
1. Вливать изменения в основную ветку как можно чаще: дробить коммиты, не накапливать тысячи строк изменений. Бонус - небольшие пулл-реквесты проще ревьювить.
2. Нужен CI, который соберет код и в идеале еще запустит тесты и позволит убедиться, что сервисы во втором проекте не ломаются от изменений в первом. Наличие такого CI дополнительно мотивирует выкладывать код в основную ветку чаще.
3. При необходимости стоит прятать новые фичи под флаги. В качестве бонуса эти флаги потом в A/B тестах можно использовать.
4. Релизить сервисы чаще, не копить изменения месяцами/годами.
Проблему разрешения конфликтов в коде все эти меры не решают, но позволяют уменьшить число конфликтов, цену ошибки и т.д.
В монорепе по-хорошему все зависимости должны храниться в самой монорепе. Версионирования библиотек как такового нет, потому что всегда используется та версия, которая закоммичена в текущей ревизии.
Изначально речь шла об организации кода, разрабатываемого внутри компании - хранить ли его в одном большом монорепозитории или в множестве маленьких - полирепозитории. Мой пример относился к сценарию, когда нужно внести изменения в несколько разных частей в кодовой базы - библиотеки, микросервисы, какие-то тулы и т.п. Допустим, мне в рамках работы над проектом надо внести изменения в код 1 сервиса и 2 библиотек, от которых сервис зависит. Если все это хранится в разных репозиториях, то нужно сделать 3 пулл-реквеста. Разве не так? В монорепозитории я могу обойтись 1 пулл-реквестом. В фейсбучной монорепе, о которой пишется в статье, это мог бы быть стек коммитов (диффов), связанных с друг другом. Такой стек можно к примеру поребейзить относительно более свежей ревизии монорепозитория одной командой. В полирепозитории в каждом подрепозитории ребейз (или мердж) нужно делать отдельно.
Ветки можно создавать в любом репозитории: и в моно-, и в поли-. Вот только в полирепе это будет N веток по числу реп, с которыми приходится работать. Не понял ваш комментарий про "ничего лишнего не прилетело". В системе контроля версий вы всегда сами выбираете, какую ревизию счекаутить. Если вы имеете в виду процесс синхронизации долгоживущей ветки с основной, то в полирепе у вас будут те же самые проблемы с мердж-конфликтами. Рано или поздно все ветки придется вмерджить в master/trunk/main etc.
После того, как все изменения закоммичены в ветки, все это добро нужно будет отправить на CI и code review. И тут снова вместо одного пулл-реквеста у вас будет N пулл-реквестов. Внутри CI ваш код будет запускаться с другими версиями соседних репозиториев, т.к. в соседних репозиториях пулл-реквесты еще не вмерджены в основную ветку. Соответственно, в разработке это придется учитывать, какие-нибудь флаги и условия расставить. Либо просто забить на CI и мерджить как есть.
Как систему не докомпозируй, а все равно на практике бывает нужно потестить изменения сразу в нескольких репозиториях (или директориях в случае монорепы). И тут монорепа гораздо удобнее. Для удобной работы с коллекцией репозиториев можно накрутить тулинг (например, как в Хромиуме), но в это нужно вкладываться.
Тем не менее бумажки, называемые рублями, в СССР были. Автоматизированную компьютерная система учёта и распределения всего производимого человечеством - это что-то из области фантастики. Хотя бы потому что эта система предполагает единые для всей планеты правила ведения этого самого учета. Сомневаюсь, что человечество способно о таком договориться. Ну и если представить что такая система есть, то там все равно внутри будет какой-то аналог денег для учёта ценности "всего производимого человечеством".
Идеальное общество, как вы его описываете, невозможно. Потому что люди в большинстве своем стараются действовать в своих интересах, которые не всегда коррелируют с интересами общества и его порядками. От соблазна получить что-то за счет окружающих никуда не деться. Кто-то может с этим бороться, а кто-то - нет. А еще к этому можно добавить обычную глупость. Идеальных людей не бывает.
Проблема в том, что бартер и прочие безденежные схемы не масштабируются. Поэтому ваш очень простой пример с домами на практике может работать, а вот с космическими программами так уже не выйдет. Даже в СССР в плановой экономике были деньги, потому что нужна мера оценки вклада каждого участника в экономику.
Ну а как в описанную вами схему вписывается запуск Вояджера? Эти же самые люди, будучи мастерами на все руки, будут еще и Вояджеры запускать из той же самой глины? На практике кирпичи, дома и Вояджеры строят специально обученные люди, а деньги это средство взаимозачетов между этими людьми.
Рейтинг Гитхат смещен в сторону опен-сорса. А на Фортране скорее всего написано много легаси-кода, который никто выкладывать в опен-сорс не торопится. Рейтинг популярности на уровне vim script - это как-то не серьезно.
А где тут запланированное устаревание? И ОС (Win 7), и браузер (Chrome) перестали обновлять, старые версии продолжают работать и будут работать еще долго. В случае с браузером так еще и исходники доступны. Автор поста просто развлекается, никаких дизассемблеров тут не нужно. В проекте Chromium есть удобный поиск по коду. Там все эти неподдерживаемые вызову Windows 7 можно найти. К примеру - ProcessPrng.
Более того, автору поста еще в прошлом посте посоветовали форк Supermium, в котором обещают поддерживать аж Windows XP. Достойной формой протеста было бы участие в проекте Supermium. Если не кодом, то хоть багрепортами. Это деятельность была бы конструктивной. Вместо этого автор сагрился на человека, который имел неосторожность представиться сотрудником Гугла.
Если люди так говорят, то этот вариант имеет право на существование. Правила не высечены в камне, норма со временем меняется.
Я согласен с автором оригинальной статьи, что левый код читается лучше, т.к. фрагмент кода небольшой, все умещается на одном экране. Однако код в камне не высекается и имеет свойство со временем меняться. Если не меняется, то скорее всего этот код никому не нужен и читабельность его может быть какой угодно, т.к. никто его читать не будет. Если же код живой, то вариант слева со временем может вырасти в нечто нечитаемое строк на 1000, а то и более. Первоначальные авторы кода могут со временем уйти в другие проекты/компании etc. Приходят какие-нибудь стажеры. Или просто люди, которым надо по-быстрому запилить фичу здесь и сейчас. Код справа более устойчив к хаотичным правкам, его читабельность со временем будет деградировать медленнее.
Эх, эту бы статью да год назад :) Мы у себя накрутили обвязку вокруг jit.p профайлера. Он в целом хорош, если нет острой необходимости провязывать стеки С/С++ с Lua. Правда, в многопоточной среде нужно быть аккуратным. К примеру, вот тут в зависимости от дефайнов сборки может не оказаться мьютекса: https://github.com/LuaJIT/LuaJIT/blob/v2.1/src/lj_profile.c#L29
Кстати, год-два назад Mike Pall вкоммитил полноценный dwarf unwind - External frame unwinding. И вроде как оно и для jit-кода должно работать. По крайней мере какие-то фреймы вот тут регистрируются: https://github.com/LuaJIT/LuaJIT/blob/v2.1/src/lj_err.c#L581
Непосредственно unwind: https://github.com/LuaJIT/LuaJIT/blob/v2.1/src/lj_err.c#L496
Дак там эмулятор на эмуляторе. То, что оно просто запустилось - это уже чудо. На вряд ли кто-то портировал код с x86 на ARM M1, т.к. исходники игр закрыты. Соответственно, запускается оно скорее всего под Розеттой, которая хоть и быстра, но нативному коду, конечно, уступает. Т.е. какое-то количество FPS на этом теряется. Далее сам код заточен под DirectX, который запускается через очередную прослойку над нативным Metal. И тут тоже без потерь FPS не обойтись.
Помимо этого, какие-то системные вызовы WinAPI могут неоптимально эмулироваться в Wine. Так же как в WSL 1.0 тормозили некоторые сисколы
На всякий случай, красивый != хорошо отформатированный. Я пока не видел, чтобы ChatGPT писал в коде какой-то откровенный бред. У вас есть пример?