Как ведущий разработчик (не руководитель) плюсую, вижу очень похожую ситуацию вокруг меня. Это касается не только процесса найма, но и профессионального роста. Люди с внешним локус-контролем создают себе ограничение в росте где-то на уровне мидла+. Они могут хорошо решать какие-то типовые задачи и быть надежным винтиком в системе. Но если ТЗ - ХЗ, нужно принимать непопулярное решение, нужно вылезти из зоны комфорта, нужно сделать нестандартный шаг, то такой разработчик отказывается идти вперед с настроем "А чего я-то сразу?". Вперед будут идти как раз те, кто, понимая свою ограниченность, все равно ищут возможность, а не гарантию, и тем самым берут ответственность на себя.
В руководстве как и в разработке есть много ненаучных моментов. Понимание того, насколько архитектура хрупкая, какой инструмент подойдет в решении проблемы в данных туманных условиях, чем из важных свойств придется сейчас пожертвовать и т.п. В данной ситуации идет речь (как я понял автора) не про навешивание ярлыков, обвинения "ага, я тебя раскусил, ты такой-сякой", а про попытку прочувствовать незнакомого другого и через это получить hint для дальнейшей оценки и вопросов. Итоговое решение будет не "по классификации Х вы попали в категорию Y, вы нам не подходите", а "вы нам не подходите, поскольку производите впечатление человека, который не научился брать на себя ответственность".
А где вы нашли сверхчувствительность? Вроде автор довольно прозрачно указал, что это история про понимание того, берет ли кандидат на себя ответственность или перекладывает на других. Это не история про субъективное ощущение "я так вижу, я художник".
Вовне как раз уходит, но не очень прозрачным образом. Вроде как и берет на себя ответственность, но "не мы, а я", "с командой экспертизой не делится", замыкает процессы на себя и т.п. Т.е. от "тащит" не потому что молодец, а потому что ненарошно создал процесс, в котором все замыкается на него. Причина - недоверие к окружающим из-за того самого смещения центра ответственности.
Возможно кто-то подобное прочитает как "он осознанно создает ситуацию незаменимости", но тут ИМХО злого умысла обычно нет.
Ага. А если пугает сложность и древность синтаксиса/логика мейкфайла, то можно использовать упрощенную альтернативу https://github.com/casey/just Что нового реализует runo кроме своего формата toml-конфига, я честно не понял.
runo это именно такой ассистент, но не для автомобилей, а для репозиториев. С ним вам больше не нужно будет искать в документации (если она есть :)) нужные команды, что-то настраивать, чтобы просто запустить тесты, или песочницу. Вам достаточно обратиться к ассистенту, он уже знает всё, что нужно об этом репозитории:
А в документации:
At this moment most part of them are just a mocks, which prints something to console, because at this moment ./runo doesn't know what test/build/... means for your project.
Т.е. проблема "нужно что-то искать и настраивать" не решена.
Помню, что на прошлой работе из-за баги в IDE она намертво зависала на одном исходном файле. vim редактировал его без проблем. Так что да, кто-то вымрет, а кто-то спокойно выживет.
Закладывать на каждом месте падения подушку - никаких ресурсов не хватит, и знать всё человек тоже не может, мясная память очень небольшого обьема на самом деле. Если для решение задачи хватает нейросети - используй нейросеть, и углубляйся в детали только тогда, когда текущий инструмент задачу уже не решает.
Вижу противоречие. Ото всех рисков не защитишься => не защищайся вообще, пока не ударит. Но это не рационализм, это беспечность.
ИИ может решить проблему быстрее, но он также может украсть вот это чувство победы. Ты вроде закрыл таску, но удовлетворения нет. А без него очень легко перегореть уже через пару месяцев: работа превращается в копипасту чужих кусков кода.
Ого, отчуждение труда по Марксу! Вообще это происходит в любой сфере экономики при дальнейшем углублении разделения труда. Раньше все операции большой задачи решаются одним человеком, он должен обладать широкой экспертизой, иметь особые свойства характера и психики. Теперь после внедрения новой технологии решение этой задачи раскололось на несколько стадий, почти каждая из которых в чем-то проще исходной. Теперь творчество не так востребовано, системность мышления не требуется, учиться нужно меньше. При этом редкие операции наоборот могут потребовать бОльших способностей - разработка ИИ в данном случае. Ну а что, технический прогресс меняет общество, меняет отношение к труду, меняет отношение труда к обществу :-)
Хотя это не всегда работает, идея заключается в том, что, когда денежная база увеличивается, для банков и учреждений становится больше валюты, что приводит к увеличению объемов кредитования, что, в свою очередь, приведет к более высоким темпам экономического роста внутри страны.
Это работает, только если есть способы приложения капитала. Мы живем в эпоху, когда таких способов практически не осталось в целом мире.
Не знаю таких :( Тут же дело в чем - понятие объективности и близости к продакшен нагрузкам у всех разное, если сравнивать RPS разладки. Есть фреймворк А и фреймворк Б. У фреймворка А есть фича Х, а у Б - нет. Нужно ли у А ее выключать на период сравнения? Или фреймворк Б нужно исключать полностью? У всех фреймворков немного разный набор функциональности, кто-то (как userver) all batteries are included, кто-то наоборот поддерживается библиотечного подхода (я предоставляю вот этот кубик, а за другие кубики отвечают другие). Вот и думай, как сравнивать апельсины и яблоки.
В итоге в techempower открутили ползунок в одну сторону и предоставили всем возможность соревноваться в минимальной конфигурации, весьма далекой от продакшена. Это имеет какой-то смысл, но весьма специфический. Для вывода, что подойдет вам, все еще лучшим вариантом является собственный бенчмарк в реалистичных (ваших) условиях.
Насчет конкрено этого бенчмарка - он достаточно синтетический. Сравнение происходит в ситуации, когда core features типа логгирования и трейсинг отключены, а драйвера БД в некоторых кейзах в топе списка написаны таким образом, что при обрыве соединений могут крашиться (не про ASP.NET). Юсервер же написан с прицелом на другой кейз - когда all batteries are on, т.е. логгирование и трейсинг включены, драйвера работают с прицелом на потенциальный разлом соединения/прокси/сети, драйвера удерживают горячий пул соединений про запас, работает механизм для получения списка работающих хендлеров и т.п. и т.д.
Это конечно же не отменяет того факта, что из движка корутин можно вытащить гораздо бОльший RPS. У нас были планы по поводу альтернативного шедулера корутин, который бы меньше трогал кеш чужих ядер, что сильно улучшило бы скалируемость по ядрам, возможно он приземлится в этом году. Но в приоритете у нас сейчас работа над другими фичами, например, над удобной работой с gRPC или над генерацией клиентов по OpenAPI схеме.
Не берусь утверждать, какая доля денег, вкладываемых в биткоин, идет туда со спекулятивной целью.
Но давайте устроим мысленный эксперимент. Скажите пожалуйста, если в середине года биткоин обвалится в ~4 раза со своего максимума, а больше половины вложений за первую половину года были сделаны со спекулятивной целью (купить дешево, продать через месяц-год дороже) домохозяйствами, вы согласитесь, что это был пузырь? Если нет, то что вы тогда можете назвать пузырем?
то в Биткоине существует постоянно восходящий тренд справедливой цены
Это не может опровергнуть или подтвердить наличие пузыря, это вообще не связанные вещи, см. выше.
То, что вы описали, называется «финансовая пирамида» или схема Понци.
Под это описание подпадает и бум на рынке недвижимости в США до 2007 года, его называют пузырем. И цены на недвижимость тоже продолжили рост после сдувания пузыря.
Это частные примеры того, как разделение труда может работать без рыночного обмена. Т.е. вы не можете утверждать «было разделение труда, а значит был рынок».
Вы так говорите, будто пузырь образуется только на ровном месте и после сдувания оставляет за собой исключительно пустошь. Финансовый пузырь — это система с положительной обратной связью, в которой доход вкладчика начинает в значительной степени образовываться из вложений последующих вкладчиков, а не иных факторов. В случае исчерпания новых вкладчиков связь рушится, и пузырь лопается или сдувается. Суть пузыря в наличии сильной положительной обратной связи, которая в момент надувания начинает играть основную роль в ценообразовании. Это ни в коей мере не исключает наличия иных факторов, которые влияют на цену актива. На рынке недвижимости периодически может образовываться пузырь, при этом цена кв.м. после лопания пузыря может быть как сильно ниже начала надувания, так и опуститься на старый уровень с дальнейшим ростом.
Возможно вы под финансовым пузырем имели ввиду какой-то очень специфический феномен, но тут я постесняюсь пытаться читать ваши мысли.
Вы снова неявно опираетесь на гипотезу о вездесущих товарных обменах. В первобытном обществе есть разделение труда с реципрокным обменом, не денежно-товарным. Мы можем рассуждать о форме обмена с натяжкой, т.к. в настоящее время даже аборигены в Южной Америке уже контактировали с цивилизацией, и поэтому они уже не «чисто» первобытные. Однако по записям первых контактов с индейцами, аборигенами Океании и Африки это были именно реципрокные обмены, а не товарные.
Разделение труда не обязательно связано с бартерными или денежно-товарными отношениями. Домашнее хозяйство ведется несколькими людьми или десятками людей, внутри него нет товарного обмена, но разделение труда есть. Крестьянская община, в которой экономические отношения строятся не на уровне независимых контрактов, а на уровне «все скидываются в общаг, а в ситуации зимы/неурожая/ЧП общаг тратится на помощь пострадавшим» и т.п. Племя, в котором есть охотники, есть шаман, есть воспитатели детей (мамы/бабушки) и т.п. Даже современная капиталистическая фирма создает внутри себя систему разделения труда, однако в рамках фирмы никакого бартерного/денежно-товарного обмена нет.
Как ведущий разработчик (не руководитель) плюсую, вижу очень похожую ситуацию вокруг меня. Это касается не только процесса найма, но и профессионального роста. Люди с внешним локус-контролем создают себе ограничение в росте где-то на уровне мидла+. Они могут хорошо решать какие-то типовые задачи и быть надежным винтиком в системе. Но если ТЗ - ХЗ, нужно принимать непопулярное решение, нужно вылезти из зоны комфорта, нужно сделать нестандартный шаг, то такой разработчик отказывается идти вперед с настроем "А чего я-то сразу?". Вперед будут идти как раз те, кто, понимая свою ограниченность, все равно ищут возможность, а не гарантию, и тем самым берут ответственность на себя.
В руководстве как и в разработке есть много ненаучных моментов. Понимание того, насколько архитектура хрупкая, какой инструмент подойдет в решении проблемы в данных туманных условиях, чем из важных свойств придется сейчас пожертвовать и т.п. В данной ситуации идет речь (как я понял автора) не про навешивание ярлыков, обвинения "ага, я тебя раскусил, ты такой-сякой", а про попытку прочувствовать незнакомого другого и через это получить hint для дальнейшей оценки и вопросов. Итоговое решение будет не "по классификации Х вы попали в категорию Y, вы нам не подходите", а "вы нам не подходите, поскольку производите впечатление человека, который не научился брать на себя ответственность".
А где вы нашли сверхчувствительность? Вроде автор довольно прозрачно указал, что это история про понимание того, берет ли кандидат на себя ответственность или перекладывает на других. Это не история про субъективное ощущение "я так вижу, я художник".
Вовне как раз уходит, но не очень прозрачным образом. Вроде как и берет на себя ответственность, но "не мы, а я", "с командой экспертизой не делится", замыкает процессы на себя и т.п. Т.е. от "тащит" не потому что молодец, а потому что ненарошно создал процесс, в котором все замыкается на него. Причина - недоверие к окружающим из-за того самого смещения центра ответственности.
Возможно кто-то подобное прочитает как "он осознанно создает ситуацию незаменимости", но тут ИМХО злого умысла обычно нет.
Ага. А если пугает сложность и древность синтаксиса/логика мейкфайла, то можно использовать упрощенную альтернативу https://github.com/casey/just
Что нового реализует runo кроме своего формата toml-конфига, я честно не понял.
А в документации:
Т.е. проблема "нужно что-то искать и настраивать" не решена.
Обман, везде обман...
Помню, что на прошлой работе из-за баги в IDE она намертво зависала на одном исходном файле. vim редактировал его без проблем. Так что да, кто-то вымрет, а кто-то спокойно выживет.
Вижу противоречие. Ото всех рисков не защитишься => не защищайся вообще, пока не ударит. Но это не рационализм, это беспечность.
Ого, отчуждение труда по Марксу!
Вообще это происходит в любой сфере экономики при дальнейшем углублении разделения труда. Раньше все операции большой задачи решаются одним человеком, он должен обладать широкой экспертизой, иметь особые свойства характера и психики. Теперь после внедрения новой технологии решение этой задачи раскололось на несколько стадий, почти каждая из которых в чем-то проще исходной. Теперь творчество не так востребовано, системность мышления не требуется, учиться нужно меньше. При этом редкие операции наоборот могут потребовать бОльших способностей - разработка ИИ в данном случае. Ну а что, технический прогресс меняет общество, меняет отношение к труду, меняет отношение труда к обществу :-)
Почему для 10 микросервисов не подходит что-то простое типа nomad? Ведь дальше вы пишете, что кубер слишком сложен для маленьких команд.
Это работает, только если есть способы приложения капитала. Мы живем в эпоху, когда таких способов практически не осталось в целом мире.
Не знаю таких :( Тут же дело в чем - понятие объективности и близости к продакшен нагрузкам у всех разное, если сравнивать RPS разладки. Есть фреймворк А и фреймворк Б. У фреймворка А есть фича Х, а у Б - нет. Нужно ли у А ее выключать на период сравнения? Или фреймворк Б нужно исключать полностью? У всех фреймворков немного разный набор функциональности, кто-то (как userver) all batteries are included, кто-то наоборот поддерживается библиотечного подхода (я предоставляю вот этот кубик, а за другие кубики отвечают другие). Вот и думай, как сравнивать апельсины и яблоки.
В итоге в techempower открутили ползунок в одну сторону и предоставили всем возможность соревноваться в минимальной конфигурации, весьма далекой от продакшена. Это имеет какой-то смысл, но весьма специфический. Для вывода, что подойдет вам, все еще лучшим вариантом является собственный бенчмарк в реалистичных (ваших) условиях.
Насчет конкрено этого бенчмарка - он достаточно синтетический. Сравнение происходит в ситуации, когда core features типа логгирования и трейсинг отключены, а драйвера БД в некоторых кейзах в топе списка написаны таким образом, что при обрыве соединений могут крашиться (не про ASP.NET). Юсервер же написан с прицелом на другой кейз - когда all batteries are on, т.е. логгирование и трейсинг включены, драйвера работают с прицелом на потенциальный разлом соединения/прокси/сети, драйвера удерживают горячий пул соединений про запас, работает механизм для получения списка работающих хендлеров и т.п. и т.д.
Это конечно же не отменяет того факта, что из движка корутин можно вытащить гораздо бОльший RPS. У нас были планы по поводу альтернативного шедулера корутин, который бы меньше трогал кеш чужих ядер, что сильно улучшило бы скалируемость по ядрам, возможно он приземлится в этом году. Но в приоритете у нас сейчас работа над другими фичами, например, над удобной работой с gRPC или над генерацией клиентов по OpenAPI схеме.
Вот тут https://userver.tech/da/d26/md_en_2userver_2framework__comparison.html есть сравнение по фичам с некоторыми фреймворками. Список конечно далеко не полный, но дает первое представление по feature parity с фреймворками, с которыми нас очень часто сравнивали.
Если вы знаете, что ASP.NET (или кто-то еще) в дефолтной поставке сравним с userver, можете дозаполнить табличку в https://github.com/userver-framework/userver/blob/develop/scripts/docs/en/userver/framework_comparison.md?plain=1
Не получится. /.. запрещены в FsClient'е. Технически кеш считывает содержимое директории и отдает только закешированное значение.
Но давайте устроим мысленный эксперимент. Скажите пожалуйста, если в середине года биткоин обвалится в ~4 раза со своего максимума, а больше половины вложений за первую половину года были сделаны со спекулятивной целью (купить дешево, продать через месяц-год дороже) домохозяйствами, вы согласитесь, что это был пузырь? Если нет, то что вы тогда можете назвать пузырем?
Это не может опровергнуть или подтвердить наличие пузыря, это вообще не связанные вещи, см. выше.
Под это описание подпадает и бум на рынке недвижимости в США до 2007 года, его называют пузырем. И цены на недвижимость тоже продолжили рост после сдувания пузыря.
Возможно вы под финансовым пузырем имели ввиду какой-то очень специфический феномен, но тут я постесняюсь пытаться читать ваши мысли.
Разделение труда не обязательно связано с бартерными или денежно-товарными отношениями. Домашнее хозяйство ведется несколькими людьми или десятками людей, внутри него нет товарного обмена, но разделение труда есть. Крестьянская община, в которой экономические отношения строятся не на уровне независимых контрактов, а на уровне «все скидываются в общаг, а в ситуации зимы/неурожая/ЧП общаг тратится на помощь пострадавшим» и т.п. Племя, в котором есть охотники, есть шаман, есть воспитатели детей (мамы/бабушки) и т.п. Даже современная капиталистическая фирма создает внутри себя систему разделения труда, однако в рамках фирмы никакого бартерного/денежно-товарного обмена нет.