Ну, я лично пока не особо запариваюсь) Как-то раз начали болеть кисти, купил себе эргономичную клаву от Microsoft, перестали болеть и мне норм.
На счёт продуктивности - моя скорость печати порядка 400 символов в минуту практически на любой клавиатуре) Эта скорость - быстрее моих мыслей) Я так быстро не формулирую мысли, как могу их печатать, так что клавиатура - самая последняя вещь влияющая на мою продуктивность)
Для меня это всё неизвестные материи :) В моей голове всё описанное - это "проблемы знания". Я вот особо не разбираюсь во всех этих клавиатурных тонкостях, а потому и не особо замечаю каких-то проблем. Мне любая клавиатура подходит по сути, я выбираю в основном из эстетических соображений.
По моему опыту, в IT можно родить пластиковую куклу, имитирующую ребёнка и продать её как настоящего) Пока клиент разбирается, можно уже родить нормального за положенные 9 месяцев.
10.1. Водитель должен вести транспортное средство со скоростью, не превышающей установленного ограничения, учитывая при этом интенсивность движения, особенности и состояние транспортного средства и груза, дорожные и метеорологические условия, в частности видимость в направлении движения. Скорость должна обеспечивать водителю возможность постоянного контроля за движением транспортного средства для выполнения требований Правил
создавать помехи другим транспортным средствам, двигаясь без необходимости со слишком малой скоростью;
В связи с чем заключаем, что если на дороге всё ровно, видимость "приемлемая" (для ИИ это оч растяжимое понятие) и все едут 80, ничего не нарушая, то ИИ вроде как обязан двигаться со скоростью потока, ибо это безопаснее с учётом всех факторов, которые нужно учесть.
Далай-Лама и его сторонники утверждают, что Далай-Лама смог узнать свои вещи из прошлой жизни (как на опознании в полицейском участке опознают преступника). Как предлагаете "отсекать"?
Бритва Хитченса, очевидно. «Что можно утверждать без доказательств, то можно отвергнуть без доказательств», так сказать.
А вы задумывались, что именно вы докажете тем фактом, что люди воспроизводят события таким образом, как они отражены в массовой культуре?
То, что всякие события и быт прошлого в кино не имеют ничего общего с реальными задокументированными вещами? И если человек несёт пургу, то очевидно откуда он этого нахватался.
Допустим, что кто-то воспроизведет события не как в массовой культуре. Что скажут ученые? Правильно. Этого нет в массовой культуре, значит воспроизводят неверно (домысливают). И это логично с точки зрения ученых.
Учёные пойдут и сверят с имеющимися фактами. Если совпадёт, скажут: "ок, возможно он и правда переродился". Если подтверждающих фактов не будет или большинство фактов будут расходиться с реальностью - скажут выдумывает (бритва Оккама).
Но ведь можно найти другое логичное объяснение. Например, что переселение не хаотично, а упорядочено массовой культурой.
А можно сказать, что по орбите вокруг солнца движется чайник. Что как бы очевидно демагогия.
Самое интересное, что законы физики и переселение душ - это независимые факторы. С моей точки зрения возможен реальный мир из любого сочетания.
С точки зрения любого учёного - любая дичь возможна, лишь бы она была экспериментально проверялась.
Почему мы считаем нереальным сочетание, когда работают законы физики и есть переселение душ? Каким законам физики это противоречит?
Вопрос бессмысленен сам по себе, потому что такой концепции как "душа" физикой не предусмотрено.
Я бы даже больше сказал - в этом мире нет ни одного чёткого определения тому, что такое "душа", и, соответственно, мы понятия не имеет переселение чего мы отрицаем.
Не верите? Спросите двух случайных людей, что такое душа, и ничего не подсказывайте, не спорьте, а просто выслушайте до конца. Потом сравните ответы.
Я в универе так спешил с получением знаний, чтобы уже начать работать, что совершенно забыл, что после выпуска пахать мне ещё лет 40, а молодость у меня одна)
В общем, можно не надо впихивать во всех подряд концентрат знаний и отправлять на конвейер? Давайте дадим людям пожить)
Позволю себе немного влезть в разговор, оч стало интересно)
И что же говорит научный метод с бритвой Оккама про Далай-Ламу?
А про какие именно аспекты мы говорим? Я не сильно знаток буддизма, о каких чудесах мы говорим в отношении далай-ламы, на которые бритва Оккама не может отсечь?
бритва Оккама в общем случае может работать как против переселения душ, так и за.
В общем случае - да. Однако в контексте гипноза думаю вполне возможно доказать, что это все выдумки. Например, если начать распрашивать про исторические факты и предметы быта, я готов поспорить, выяснится что люди под гипнозом воспроизводят события таким образом, каким они отражены в массовой культуре, а не такими, какие они были на самом деле.
Я не знаю ни что такое GLSL, ни над чем вы работаете. Могу сказать, что если вы работаете над чем-то один или маленькой командой - вам точно не нужна монорепа. Вы не получите никакой выгоды от неё.
Речь ведётся о кодовой базе над которой работают ежедневно 100+ человек минимум.
Проблемы начинаются не тогда, когда API расширяется.
Проблемы всегда начинаются тогда, когда API ломается. Этот момент всегда максимально оттягивают, но это всё равно происходит. И вот тогда начинается веселье :)
Проблемы продолжаются тогда, когда в API обнаруживается уязвимость. Монорепа позволяет раскатать гарантированно фикс безопасности по всей кодовой базе за один коммит.
Хуже еще бывает, когда API ломается не по принципу поломки сигнатуры, а по изменению логики в передаваемой через API информации. Например, мы передавали некоторый документ в котором было полюшко quantity и оно означало количество денег в единицах валюты. А потом, по какой-то неведомой причине, quantity стало означать количество денег в тысячах единиц валюты. Например законодательство изменилось или там гиперинфляция случилась. Исправить такое в монорепе - куда проще. Хотя описаные события запускают такие волны говна, что так делают раз в тысячеление, но на масштабах жизни корпораций - это вполне себе возможный сценарий.
P.S.
Немножко проблем случается, когда реализация API под капотом меняется. Высокопроизводительный код (а у Яндекса он явно такой), иногда оч болезненно реагирует на внутренние изменения во внешне одинаковом API. Но это всегда уникальные случаи, тут моно/много-репность на ситуация никак не влияет.
как пакет с аккуратным версионированием по semver.
Если честно, я за всю карьеру не встречал ни одной библиотеки, в которой бы "аккуратно соблюдался semver" на сколько-нибудь долгом промежутке времени. Вот вообще ни одной. Я понимаю, что я один, а библиотек очень много, так что 100% такие существуют, но на деле - всем ваще пофиг.
Что будем делать, когда проекты, от которых мы зависим внезапно начинают использовать две разных схемы версионирования. Вот тут и начинается веселье.
Иначе это дорога в ад
Фраза "Dependency hell" существует не просто так. Разбитие кода на независимые репозитории - это тоже дорога в ад :)
в котором никогда не знаешь что и где тебе какое-либо изменение может сломать.
В том и прикол монорепы. Любое ломающее изменение - сломает тебе весь репозиторий. И ты это заметишь сразу. Из плюсов - ты можешь исправить проблему сразу везде, пускай это и потребует ресурсов. Но точно меньших, чем решать эту проблему силами разных команд 10 раз подряд, да еще и в разные временные интервалы.
Да, особенно удобно это для CI, которому каждый раз надо либо пересобирать и тестировать всю огромную монорепу
Эта проблема решается более продвинутой настройкой CI с анализом списка измененных файлов в коммите, не более. Как я и сказал - для поддержки монорепы в работоспособном состоянии - нужна отдельная команда. Не "группка человек из разных команд", а реально отдельная команда билд-инженеров.
для микросервисной архитектуры, по личному опыту, это боль.
Монорепа/"многорепа" и монолит/микросервис - это проблемы из разных миров, которые между собой мало пересекаются.
- Монорепа/"многорепа" - это способы решения проблемы шаринга кодовой базы между разными продуктами/сервисами
- Монолит/микросервис - это способы решения проблемы взаимодействия разных частей системы между собой.
Я слабо представляю как эти проблемы связаны между собой. Они параллеьны друг другу.
Опять же, надо помнить, что говоря о монорепе положительно, я обычно говорю только в ключе С++ разработки. Потому что в С++ до недавнего времени не было модулей вообще, а нормальных - нет и сегодня, на мой взгляд. И монорепа для С++ решает множество проблем.
Для языков с нормальными модулями и пакетными менеджерами, вероятно, монорепа и правда монструозная ненужная конструкция.
Не понял аналогии, ессчессно)
А смысл? :D
Ну, я лично пока не особо запариваюсь) Как-то раз начали болеть кисти, купил себе эргономичную клаву от Microsoft, перестали болеть и мне норм.
На счёт продуктивности - моя скорость печати порядка 400 символов в минуту практически на любой клавиатуре) Эта скорость - быстрее моих мыслей) Я так быстро не формулирую мысли, как могу их печатать, так что клавиатура - самая последняя вещь влияющая на мою продуктивность)
Для меня это всё неизвестные материи :) В моей голове всё описанное - это "проблемы знания". Я вот особо не разбираюсь во всех этих клавиатурных тонкостях, а потому и не особо замечаю каких-то проблем. Мне любая клавиатура подходит по сути, я выбираю в основном из эстетических соображений.
По моему опыту, в IT можно родить пластиковую куклу, имитирующую ребёнка и продать её как настоящего) Пока клиент разбирается, можно уже родить нормального за положенные 9 месяцев.
Не, ну если нужны ещё нищебродские варианты, то у меня есть такой:
https://aliexpress.ru/item/33036627729.html?item_id=33036627729&sku_id=12000021624058784
Отличная клава, два года пользую за вторым компом, никаких нареканий. Есть разные исполнения, урезанные и полноразмерные.
У меня ровно противоположный опыт в плане усилий для нажатия. Мембранные оч легко тыкаются. Механические по ощущениям куда сильнее надо тыкать.
Мои blue switch не то что хрустят, я как будто бы за печатной машинкой сижу :) Каеф)
Открываем ПДД, пункт 10.1
А затем пункт 10.5
В связи с чем заключаем, что если на дороге всё ровно, видимость "приемлемая" (для ИИ это оч растяжимое понятие) и все едут 80, ничего не нарушая, то ИИ вроде как обязан двигаться со скоростью потока, ибо это безопаснее с учётом всех факторов, которые нужно учесть.
Бритва Хитченса, очевидно. «Что можно утверждать без доказательств, то можно отвергнуть без доказательств», так сказать.
То, что всякие события и быт прошлого в кино не имеют ничего общего с реальными задокументированными вещами? И если человек несёт пургу, то очевидно откуда он этого нахватался.
Учёные пойдут и сверят с имеющимися фактами. Если совпадёт, скажут: "ок, возможно он и правда переродился". Если подтверждающих фактов не будет или большинство фактов будут расходиться с реальностью - скажут выдумывает (бритва Оккама).
А можно сказать, что по орбите вокруг солнца движется чайник. Что как бы очевидно демагогия.
С точки зрения любого учёного - любая дичь возможна, лишь бы она была экспериментально проверялась.
Вопрос бессмысленен сам по себе, потому что такой концепции как "душа" физикой не предусмотрено.
Я бы даже больше сказал - в этом мире нет ни одного чёткого определения тому, что такое "душа", и, соответственно, мы понятия не имеет переселение чего мы отрицаем.
Не верите? Спросите двух случайных людей, что такое душа, и ничего не подсказывайте, не спорьте, а просто выслушайте до конца. Потом сравните ответы.
Я в универе так спешил с получением знаний, чтобы уже начать работать, что совершенно забыл, что после выпуска пахать мне ещё лет 40, а молодость у меня одна)
В общем, можно не надо впихивать во всех подряд концентрат знаний и отправлять на конвейер? Давайте дадим людям пожить)
Позволю себе немного влезть в разговор, оч стало интересно)
А про какие именно аспекты мы говорим? Я не сильно знаток буддизма, о каких чудесах мы говорим в отношении далай-ламы, на которые бритва Оккама не может отсечь?
В общем случае - да. Однако в контексте гипноза думаю вполне возможно доказать, что это все выдумки. Например, если начать распрашивать про исторические факты и предметы быта, я готов поспорить, выяснится что люди под гипнозом воспроизводят события таким образом, каким они отражены в массовой культуре, а не такими, какие они были на самом деле.
Откуда я знаю, я ещё не заглядывал.
Мне не хватает возможности рисовать ровные линии и стрелки) Например по нажатию shift или отдельной кнопкой на панели.
Ну, например, так можно обозвать рабочие потоки)
У нас с женой было 65% от квартиры, но даже оставшееся - это охренеть сколько миллионов рублей)
Вы видели сколько-нибудь крупный проект у которого не было никаких проблем с архитектурой?
Вы видели хоть один проект, заточенный под реально высокую производительность, в котором вообще не используется грязные хаки?
Вы видели хоть раз кодовую базу для группы (от 5 штук) взаимоинтегрированных продуктов, в которой бы не возникало описываемых мною проблем?
Не, если видели такой и он был на С++ - скажите мне где, я пойду туда работать. На текущий момент я такого единорога не встречал.
Я не знаю ни что такое GLSL, ни над чем вы работаете. Могу сказать, что если вы работаете над чем-то один или маленькой командой - вам точно не нужна монорепа. Вы не получите никакой выгоды от неё.
Речь ведётся о кодовой базе над которой работают ежедневно 100+ человек минимум.
Проблемы начинаются не тогда, когда API расширяется.
Проблемы всегда начинаются тогда, когда API ломается. Этот момент всегда максимально оттягивают, но это всё равно происходит. И вот тогда начинается веселье :)
Проблемы продолжаются тогда, когда в API обнаруживается уязвимость. Монорепа позволяет раскатать гарантированно фикс безопасности по всей кодовой базе за один коммит.
Хуже еще бывает, когда API ломается не по принципу поломки сигнатуры, а по изменению логики в передаваемой через API информации. Например, мы передавали некоторый документ в котором было полюшко quantity и оно означало количество денег в единицах валюты. А потом, по какой-то неведомой причине, quantity стало означать количество денег в тысячах единиц валюты. Например законодательство изменилось или там гиперинфляция случилась. Исправить такое в монорепе - куда проще. Хотя описаные события запускают такие волны говна, что так делают раз в тысячеление, но на масштабах жизни корпораций - это вполне себе возможный сценарий.
P.S.
Немножко проблем случается, когда реализация API под капотом меняется. Высокопроизводительный код (а у Яндекса он явно такой), иногда оч болезненно реагирует на внутренние изменения во внешне одинаковом API. Но это всегда уникальные случаи, тут моно/много-репность на ситуация никак не влияет.
Если честно, я за всю карьеру не встречал ни одной библиотеки, в которой бы "аккуратно соблюдался semver" на сколько-нибудь долгом промежутке времени. Вот вообще ни одной. Я понимаю, что я один, а библиотек очень много, так что 100% такие существуют, но на деле - всем ваще пофиг.
Что будем делать, когда проекты, от которых мы зависим внезапно начинают использовать две разных схемы версионирования. Вот тут и начинается веселье.
Фраза "Dependency hell" существует не просто так. Разбитие кода на независимые репозитории - это тоже дорога в ад :)
В том и прикол монорепы. Любое ломающее изменение - сломает тебе весь репозиторий. И ты это заметишь сразу. Из плюсов - ты можешь исправить проблему сразу везде, пускай это и потребует ресурсов. Но точно меньших, чем решать эту проблему силами разных команд 10 раз подряд, да еще и в разные временные интервалы.
Эта проблема решается более продвинутой настройкой CI с анализом списка измененных файлов в коммите, не более. Как я и сказал - для поддержки монорепы в работоспособном состоянии - нужна отдельная команда. Не "группка человек из разных команд", а реально отдельная команда билд-инженеров.
Монорепа/"многорепа" и монолит/микросервис - это проблемы из разных миров, которые между собой мало пересекаются.
- Монорепа/"многорепа" - это способы решения проблемы шаринга кодовой базы между разными продуктами/сервисами
- Монолит/микросервис - это способы решения проблемы взаимодействия разных частей системы между собой.
Я слабо представляю как эти проблемы связаны между собой. Они параллеьны друг другу.
Опять же, надо помнить, что говоря о монорепе положительно, я обычно говорю только в ключе С++ разработки. Потому что в С++ до недавнего времени не было модулей вообще, а нормальных - нет и сегодня, на мой взгляд. И монорепа для С++ решает множество проблем.
Для языков с нормальными модулями и пакетными менеджерами, вероятно, монорепа и правда монструозная ненужная конструкция.