>необходимость свободного порядка слов в русском под вопросом (раз английский без него обходится).
Свободный порядок это misnomer в том плане, что он совершенно не свободный и выполняет конкретную функцию: сравните предложения "мальчик вошел в комнату" и "в комнату вошел мальчик". В первом случае мальчик определенный, во втором - неопределенный. В англ. языке это решается неопред. артиклем, но у свободного порядка здесь есть преимущество в том, что акцентировать информацию можно не только у существительных, но и у любых частей речи: "люблю я тебя" vs. "я тебя люблю". В англ. обходятся или чисто интонацией (что в письменной речи можно решить только италиком, например) или неуклюжими перифрастическимт конструкциями вроде "что я на самом деле делаю так это..." или "это именно тот человек, который..."
>А кто вам будет архитектуру делать? Кто будет сводить беков и фрнотов к одному решению когда они опять подерутся на тему реста
Techlead? Достаточно довольно базовое понимание фронта/бэка чтобы разрешить спор ("а вот тут у нас оптимистичный UI", "а вот тут фронт предлагает делать запросы в цикле, что нагрузит БД"). Не знаю, считается ли это фуллстеком :)
В случае с оригинальным вопросом про небеса/окна правильный ответ - разные основы, унаследованные от ПИЕ, которые в ед. числе слились. Есть ведь ещё u-основы, например: сын - сыновья.
В праиндовропейском было слово nebhos "облако, небо" (дало др.греч. nephos), множественное число было nebhesa, совершенно стандартное окончание -a для среднего рода (с чередованием основы -os- / -es-), что в греч. дало nephea (тоже не двойственное ни разу)
В славянских же просто отвалилось конечное -s, разве нет? Не совсем понял, при чем тут двойственное число.
>Причина исчезновения глагола-связки в русском языке, думаю, таится в том, что в предложении либо избыточен глагол-связка, либо местоимение
Есть мнение, что связка у предикатива начала опускаться при кратких прилагательных/причастиях в третьем лице уже в праславянском. В чешском и польском у 3 лица отсутствует связка je: чеш. on byl вместо on je byl
>jsem byl v Velkém Novgorodu
Если местоимение опущено, то порядок другой: byl jsem. Не уверен, но в др.-русском, по-моему, тоже " былъ есмь" должен быть.
>А 2 года назад начал путаться. Чем дальше — тем больше
Я имел привычку использовать пароли на основе алгоритма, вычисляемого в уме (в основном для throwaway-регистрации), но последнее время стали происходить странные вещи - вроде всё правильно сделал, а не подходит :)
>Теперь перечитайте — и станет понятно, что микросервисы чаще всего не нужны на старте продукта.
Про микросервисы обычно разговоры заводятся в контексте темы "распил монолита" (на конфах и в различных статьях). Т.е. по факту так и происходит у большинства - сначала на старте пилится монолит, потом с ростом приходят к микросервисам как решению насущных проблем масштабирования. Мне интересно, есть ли проекты изначально микросервисные и интересно узнать их судьбу
Думается, микросервисы популяризовали большие компании, чьи продукты зачастую являются по факту группой нескольких разных интегрированных сервисов, с разными командами, циклами релизов и т.д. - и там это разумно разделить кодовую базу на разные приложения, у которых только общие api gateway и UI, и некоторое взаимодействие между собой. Плюс масштабирование, отказоустойчивость, все дела. Однако подход стали переменять более мелкие компании, потому что взрослые ребята делают так же -- хотя это им это нафиг не надо. А потом пошел оверенджениринг.
Это конечно правильные общие слова, но если в продукте много команд и релизы случаются много раз каждый день, то конфликты в общей кодовой базе будут случаться сильно регулярно и тормозить процесс. Конечно если команда одна и релизы происходят раз в неделю, то плюсов от микросервисов не будет вообще никаких.
>Если команда владеющая библиотекой может «внезапно» поменять АПИ своих интерефейсов то также внезапно она может поменять и свой протокол.
Тут не то чтобы внезапность - нужды одной команды требуют изменения в общий компонент, и всем остальным командам нужно потратить время на синхронизацию (а часто, бывает, синхронизирует исходная команда и лезет в чужой код, потому что "изменение-то маленькое"), иначе сборка не случится, а в прод нужно уже завтра.
DLL hell - абсолютно такая же проблема, поэтому и придумали версионирование. Изменение затрагивают только одно приложение (модуль) и не имеет полномасшатбных изменений по всей системе. Старая версия библиотеки будет продолжать работать как и раньше, пока её не обновят в отдельно взятом микросервисе.
Основная боль по моему опыту в продуктовом коде на Go это работа с массивами: есть ли объект в слайсе, сконвертировать слайс одного типа в другой (что часто приходится делать из-за отсутствия ковариантности массивов). Сейчас планируют добавить стандартный пакет slices с использованием дженериков, что покроет (по крайней мере, для меня) большую часть кейсов. При этом в языке будет поддержка выведения типов дженерик-параметров (не нужно писать тип параметра явно), поэтому в местах вызова клиентский код будет выглядеть как старый добрый Go без наворотов. Сейчас уже существуют дженерик-функции вроде len, просто они сейчас реализованы как магические интринсики, а теперь это будет расширяемый подход
Мономорфизация может увеличить время компиляции и раздуть бинарник (мы в C++ на проекте среднего размера широко использовали шаблоны из boost и бинарник дорос до нескольких сотен МБ), а это противоречит постулатам Go о быстрой компиляции. Вообще, одна реализация на несколько специализаций не есть что-то из вон выходящее. В C# тоже нормальные reified generics, однако в Mono (про .NET Core точно не помню) используется generic code sharing для reference-типов, т.к. там реально машинный код почти ничем не будет отличаться (указатели на reference-типы всегда одной ширины); исключением там только проверки вроде is/as/typeof, для этого в функцию добавляется скрытый аргумент типа (ЕМНИП) и делаются доп. проверки в рантайме.
Не во всяком монолите можно использовать разные версии общих библиотек одновременно. Если команда 1 обновила общую зависимость, то код команды 2 может сломаться. С микросервисами можно применить версионирование, т.е. один микросервис использует одну версию, другой - вторую, и при явном обновлении зависимости проводить осознанное тестирование
Такие проблемы есть и в любом монолите, использующем асинхронные обработчики событий или более 1 атомарной операции на команду (например если есть сетевые вызовы в сторонние сервисы, которые в одну транзакцию с БД не положишь).
Тут основные плюсы с точки зрения процессов это независимый деплой (проще тестировать и выкатывать/откатывать по кусочкам) и гарантия того, что другие команды не сунутся туда, куда им соваться не нужно, и не будет конфликтов при мержах (изоляция), также форсируется общение через чётко документированное API (нельзя взять и накостылять что-то в обход). Когда над монолитом работают несколько команд, постоянно что-то отваливается/не собирается, нужно разруливать какие-то конфликты при мержах, другая команда залезла в твой код и накуролесила, поменяли общий класс-зависимость и поведение немного поменялось, но сломало твои кейсы и т.д. (это даже при DDD). С микросервисами вообще в этом плане лепота - присутствует какая-то стабильность, при переходе от задачи к задаче и мержах старых задач есть уверенность, что оно с вероятностью 99.99÷ заведется без проблем и будет работать так же, как в прошлый раз оставил
Такой подход имеет смысл, если у сотрудников в среднем низкий уровень ответственности/мотивации и в компании большая текучка. Что-то вроде Красного-Белого, например. Т.е. статья больше наводит на мысли о том, почему авторы статьи попали в такую ситуацию. Может быть, решать причину, а не следствия? Как говорится, рыба гниёт с головы. Вероятно, условия труда в компании не привлекательные, в итоге приходится набирать не пойми кого. Если задачи решаются в срок и откровенного саботажа нет - чего плохого в том, чтобы делать небольшие перерывы в течение рабочего дня? Интеллектуальный труд тоже требует отдыха; если сотрудник будет работать 8 часов без перерыва под пристальным надзором, его производительность только снизится, мы же не роботы.
>Хотя в этих видеозвонках звук был отключен по соображениям безопасности, обезьяны проявляли повышенный интерес к тому, что же делают их родственники в другом месте
По соображениям безопасности? Чтобы не допустить Планету Обезьян?
>необходимость свободного порядка слов в русском под вопросом (раз английский без него обходится).
Свободный порядок это misnomer в том плане, что он совершенно не свободный и выполняет конкретную функцию: сравните предложения "мальчик вошел в комнату" и "в комнату вошел мальчик". В первом случае мальчик определенный, во втором - неопределенный. В англ. языке это решается неопред. артиклем, но у свободного порядка здесь есть преимущество в том, что акцентировать информацию можно не только у существительных, но и у любых частей речи: "люблю я тебя" vs. "я тебя люблю". В англ. обходятся или чисто интонацией (что в письменной речи можно решить только италиком, например) или неуклюжими перифрастическимт конструкциями вроде "что я на самом деле делаю так это..." или "это именно тот человек, который..."
>А кто вам будет архитектуру делать? Кто будет сводить беков и фрнотов к одному решению когда они опять подерутся на тему реста
Techlead? Достаточно довольно базовое понимание фронта/бэка чтобы разрешить спор ("а вот тут у нас оптимистичный UI", "а вот тут фронт предлагает делать запросы в цикле, что нагрузит БД"). Не знаю, считается ли это фуллстеком :)
В случае с оригинальным вопросом про небеса/окна правильный ответ - разные основы, унаследованные от ПИЕ, которые в ед. числе слились. Есть ведь ещё u-основы, например: сын - сыновья.
Про очи верно, но немного о другом :)
Блюпринты это скорее для гейм-дизайнеров, чем программистов, насколько я понял.
В праиндовропейском было слово nebhos "облако, небо" (дало др.греч. nephos), множественное число было nebhesa, совершенно стандартное окончание -a для среднего рода (с чередованием основы -os- / -es-), что в греч. дало nephea (тоже не двойственное ни разу)
В славянских же просто отвалилось конечное -s, разве нет? Не совсем понял, при чем тут двойственное число.
>Причина исчезновения глагола-связки в русском языке, думаю, таится в том, что в предложении либо избыточен глагол-связка, либо местоимение
Есть мнение, что связка у предикатива начала опускаться при кратких прилагательных/причастиях в третьем лице уже в праславянском. В чешском и польском у 3 лица отсутствует связка je: чеш. on byl вместо on je byl
>jsem byl v Velkém Novgorodu
Если местоимение опущено, то порядок другой: byl jsem. Не уверен, но в др.-русском, по-моему, тоже " былъ есмь" должен быть.
>А 2 года назад начал путаться. Чем дальше — тем больше
Я имел привычку использовать пароли на основе алгоритма, вычисляемого в уме (в основном для throwaway-регистрации), но последнее время стали происходить странные вещи - вроде всё правильно сделал, а не подходит :)
>Теперь перечитайте — и станет понятно, что микросервисы чаще всего не нужны на старте продукта.
Про микросервисы обычно разговоры заводятся в контексте темы "распил монолита" (на конфах и в различных статьях). Т.е. по факту так и происходит у большинства - сначала на старте пилится монолит, потом с ростом приходят к микросервисам как решению насущных проблем масштабирования. Мне интересно, есть ли проекты изначально микросервисные и интересно узнать их судьбу
Думается, микросервисы популяризовали большие компании, чьи продукты зачастую являются по факту группой нескольких разных интегрированных сервисов, с разными командами, циклами релизов и т.д. - и там это разумно разделить кодовую базу на разные приложения, у которых только общие api gateway и UI, и некоторое взаимодействие между собой. Плюс масштабирование, отказоустойчивость, все дела. Однако подход стали переменять более мелкие компании, потому что взрослые ребята делают так же -- хотя это им это нафиг не надо. А потом пошел оверенджениринг.
Это конечно правильные общие слова, но если в продукте много команд и релизы случаются много раз каждый день, то конфликты в общей кодовой базе будут случаться сильно регулярно и тормозить процесс. Конечно если команда одна и релизы происходят раз в неделю, то плюсов от микросервисов не будет вообще никаких.
>точно так же как одновременно не вызваются разные версии API одного и того же микросервиса
Вполне вызывают при rolling release или canary-релизах, когда одновременно разные инстансы ссылаются на две версии API
См. комментарий выше про DLL Hell
>Если команда владеющая библиотекой может «внезапно» поменять АПИ своих интерефейсов то также внезапно она может поменять и свой протокол.
Тут не то чтобы внезапность - нужды одной команды требуют изменения в общий компонент, и всем остальным командам нужно потратить время на синхронизацию (а часто, бывает, синхронизирует исходная команда и лезет в чужой код, потому что "изменение-то маленькое"), иначе сборка не случится, а в прод нужно уже завтра.
DLL hell - абсолютно такая же проблема, поэтому и придумали версионирование. Изменение затрагивают только одно приложение (модуль) и не имеет полномасшатбных изменений по всей системе. Старая версия библиотеки будет продолжать работать как и раньше, пока её не обновят в отдельно взятом микросервисе.
Основная боль по моему опыту в продуктовом коде на Go это работа с массивами: есть ли объект в слайсе, сконвертировать слайс одного типа в другой (что часто приходится делать из-за отсутствия ковариантности массивов). Сейчас планируют добавить стандартный пакет slices с использованием дженериков, что покроет (по крайней мере, для меня) большую часть кейсов. При этом в языке будет поддержка выведения типов дженерик-параметров (не нужно писать тип параметра явно), поэтому в местах вызова клиентский код будет выглядеть как старый добрый Go без наворотов. Сейчас уже существуют дженерик-функции вроде len, просто они сейчас реализованы как магические интринсики, а теперь это будет расширяемый подход
Мономорфизация может увеличить время компиляции и раздуть бинарник (мы в C++ на проекте среднего размера широко использовали шаблоны из boost и бинарник дорос до нескольких сотен МБ), а это противоречит постулатам Go о быстрой компиляции. Вообще, одна реализация на несколько специализаций не есть что-то из вон выходящее. В C# тоже нормальные reified generics, однако в Mono (про .NET Core точно не помню) используется generic code sharing для reference-типов, т.к. там реально машинный код почти ничем не будет отличаться (указатели на reference-типы всегда одной ширины); исключением там только проверки вроде is/as/typeof, для этого в функцию добавляется скрытый аргумент типа (ЕМНИП) и делаются доп. проверки в рантайме.
>Библиотеки никто не отменял.
Не во всяком монолите можно использовать разные версии общих библиотек одновременно. Если команда 1 обновила общую зависимость, то код команды 2 может сломаться. С микросервисами можно применить версионирование, т.е. один микросервис использует одну версию, другой - вторую, и при явном обновлении зависимости проводить осознанное тестирование
Такие проблемы есть и в любом монолите, использующем асинхронные обработчики событий или более 1 атомарной операции на команду (например если есть сетевые вызовы в сторонние сервисы, которые в одну транзакцию с БД не положишь).
Тут основные плюсы с точки зрения процессов это независимый деплой (проще тестировать и выкатывать/откатывать по кусочкам) и гарантия того, что другие команды не сунутся туда, куда им соваться не нужно, и не будет конфликтов при мержах (изоляция), также форсируется общение через чётко документированное API (нельзя взять и накостылять что-то в обход). Когда над монолитом работают несколько команд, постоянно что-то отваливается/не собирается, нужно разруливать какие-то конфликты при мержах, другая команда залезла в твой код и накуролесила, поменяли общий класс-зависимость и поведение немного поменялось, но сломало твои кейсы и т.д. (это даже при DDD). С микросервисами вообще в этом плане лепота - присутствует какая-то стабильность, при переходе от задачи к задаче и мержах старых задач есть уверенность, что оно с вероятностью 99.99÷ заведется без проблем и будет работать так же, как в прошлый раз оставил
Такой подход имеет смысл, если у сотрудников в среднем низкий уровень ответственности/мотивации и в компании большая текучка. Что-то вроде Красного-Белого, например. Т.е. статья больше наводит на мысли о том, почему авторы статьи попали в такую ситуацию. Может быть, решать причину, а не следствия? Как говорится, рыба гниёт с головы. Вероятно, условия труда в компании не привлекательные, в итоге приходится набирать не пойми кого. Если задачи решаются в срок и откровенного саботажа нет - чего плохого в том, чтобы делать небольшие перерывы в течение рабочего дня? Интеллектуальный труд тоже требует отдыха; если сотрудник будет работать 8 часов без перерыва под пристальным надзором, его производительность только снизится, мы же не роботы.
Автор явно свежие white papers активно не читает, иначе бы не порол чушь.
Статьи из разряда "за последние 25 лет ничего путного не изобрели" были и 25 лет назад.
>Хотя в этих видеозвонках звук был отключен по соображениям безопасности, обезьяны проявляли повышенный интерес к тому, что же делают их родственники в другом месте
По соображениям безопасности? Чтобы не допустить Планету Обезьян?