С дисциплиной проблемы? :) Сложнее в качественном монолите только удерживать себя от соблазна обращаться к внутренностям (включая таблицы базы) соседних модулей напрямую, а не через их фасад, который DTO принимет/отдаёт.
А как только кто-то один раз сделал шаг влево — то тут же качественный монолит превращается в некачественный и веселуха не заканчивается никогда. В микросервисной архитектуре это сделать практически невозможно. А в силу специфики разработки и того, что в команде, чаще за все, не все опытные разработчики, таких шагов влево делается очень много.
Как это может быть потенциально я представляю, но выдвигать такое утверждение и, я так понимаю, на его основании писать статью мне кажется черезмерным.
Типы могут доказать, что программа в целом безопасна
Это в каком-таком языке? В более-менее популярных остается куча проблем, от вызовов cast и null exception до panic или core dump при использовании сишных либ.
Если вы поднимите свой почтовый сервер, то совпадение с гуглом у вас заведомо будет хреновым, потому что «стандартные проверки» не работают уже двадцать лет
Стандартные проверки еще как работают. Попробуйте себе отправить письмо без правильных подписей в DNS и посмотрите, как оно моментально улетает в спам практически у всех, в том числе у гугла. Мне кажется, лучше говорить, что используются не только стандартные проверки.
Это даст вам возможность проверить утверждения гугла о том, что кандидаты сами виноваты. Потому что, скажем, если совпадение с гуглом будет там 50-70%, то это уже повод для кандидатов задуматся.
Во-первых, практически невозможно определить, решил это робот сам или ему кто-то помог — алгоритмически, обучением модной нейросетки на правильном наборе данных или ручной коррекцией. Только через суд и долгие упорные допросы там сотрудников, причастных к процессу, в надежде, что кто-нибудь сознается (практика так допросов уже есть, заметим, но это явно не то решение, которое можно применять быстро и эффективно).
А построить регрессию и проанализировать факторы? Или хотя попробовать поднять свой почтовый сервер и настроить стандартные проверки? Сразу как всегда злобная корпорация виновата :(
Это намного хуже — вы увидите правду, только правду, ничего кроме правды. Просто не всю правду. Робот так решил. Вы будете довольны.
Особенно, если регулярная рассылка от кандидата один раз из пяти недоходит. Никто ничего не заподозрит, да.
Не согласен. До тех пор пока бизнес может по желанию левой пятки уволить сотрудника, пока у сотрудника нет доли в бизнесе — ничего общего, кроме трудового договора у них нет.
По желанию левой пятки уволить сотрудника, а потом опять выходить на рынок и несколько месяцев искать нового человека, терпя убытки от нереализованных задач. Какой-то странный бизнес.
Программисты обычно измеряют профессиональный рост сложностью технических задач, которые они стали способны решать. Тот факт, что способность создать стабильное, хорошо спроектировннае высоконагруженное приложение будут использовать миллионы людей, крут не потому что "смотри сколько людей это используют", а потому, что "смотри как я заставил эту железку работать!"
Эм… а что не так то с "смотри сколько людей это используют"? Мне вот, как программисту такое тоже нравится.
Пассаж про запудривание мозгов — он вообще параллелен сторипоинтам. Это просто заметка о том, что в каждой статье как мантру повторяют, что все эти алжайлы и прочее — это ведь не только бизнесу, это нужно больше всего мне самому. Я так не считаю.
А как бы вы хотели вести разработку, в духе "Просто пиши код"? Когда все просто пилят, пилят, пилят без конца и края?)
Страдает только бизнес. Работникам, в основном, плюс/минус наплевать.
Это прям в крупных компаниях. В средних обычно страдания бизнеса выливаются, например, в сокращении расходов на офис (был кулер? Ну, теперь будет фильтр), задержке зарплаты и уменьшение лояльности бизнеса к разработчикам. Потому что цикл обратной связи от владельца бизнеса 2-3 человека и докадывается до всех. Причем самое приятное в этой ситуации то, что как бы вам нужно просто ее перестрадать.
Он страдает, потому что хочет страдать, очевидно. Если бы меня не отпускали в отпуск на регулярной основе, я бы просто уволился и разбирайтесь со своей проблемой как хотите.
Есть такая штука, называется ответственность. Бывает она, например, перед коллегами или начальством. На словах обычно все как Львы Толстые, а когда доходит до дела, то вспоминаешь, что модуль пилил только ты, он тебе как родной, а задачи на него все приходят и приходят.
Притом, что я разработчик :) Если задача рутинная, скучная и монотонная и я не хочу её делать, я конечно пойду её делать из под палки, но лояльность моя снизится. Вот соббсно и вся история. Все эти agile штуки ведут к уменьшению моей… ну, эффективность не то слово, скорее производительности. Я буду пилить говёную задачу "лишь бы отстали", что в последующем выльется в проблемы.
А кто же тогда будет делать рутинные задачи? Бедняга, который более уступчивый и в итоге потом тихо уволится? И вот тогда все эти прекрасные задачи свялятся на вас полным скопом и не уверен, что те выиграши в продуктивности, которые были получены окупятся.
Я не отрицаю потребность бизнеса в управляемых болванчиках. Я не люблю когда мне вливают в уши, что я должен это любить.
Мне интересно, почему как лояльность, так сразу болванчики? Для вас лояльность это что в духе "люби компанию и делай для нее все" или, например, то что начальник более лояльно относится к вашему графику, а вы взамен иногда по 1-2 часа на выходных уделяете работе?
да и в целом, заниматься тем, что тебе не оч нравится (иначе почему ты в этом еще не хорош?)
Потому что это скучная монотонная работа (формочка или другая задача, которая занимает кучу времени чисто из-за ее нудности или копание в легаси-части проекта? Потому что вам идеологически не нравится задача? Вариантов на самом деле очень много. Ну и да, причем тут "нравится или нет", если тут скорее вопрос "есть ли компетенция в этой части проекта или нет"? Получается немного подмена понятий.
Зато разработчики довольны, ибо занимаются тем, что нравится :)
Почему-то, обычно разработчики страдают от серьезной нагрузки, потому что их модуль никто другой не знает и задачи в нем может пилить только он, а так же от отсутствия отпуска, потому что даже если он в него пошел — баг в его модуле тоже только он может починить. Вообще не знаю никого, кто был бы доволен ситуацией в пункте 2.
Особенно ситуация в пункте 2 выглядит классно, когда разработчик внезапно заболевает, критически важная задача для бизнеса не сделана или критически важная бага не исправлена, а вы понимаете, что заменить разработчика за вменяемый срок (условно, до месяца) вообще некем. В итоге просто все ждут разработчика и страдают.
Все эти управленческие свистоперделки — они только и только про потребности бизнеса, потребности разработчика в них никто и не пытается запихнут
Вы отрицаете потребность бизнеса в лояльных сотрудниках? Учитывая что лояльность часто формировать дешевле, чем поднимать ЗП, что бы компенсировать ее отсутствие.
Часть библиотек и тулов не готовы к UTF-8 исходному коду.
Часть старых тулзов, которые еще работают на исключительно python2? Или вы про какие-то другие тулзы?
К гибкости языка это отношения не имеет.
Поправьте меня, если я не прав, но мне кажется, что на go довольно неудобно будет строить архитектуру отличную от горутины + CSP? Я это имел ввиду под гибкостью.
Ну, я же могу в github удалить тег и тегнуть другой коммит? Или прокси навсегда кеширует у себя значение? В таком случае, там хотя бы можно сделать yanked релиз (удалить пакет из прокси)?
Но ведь передеплоить пакет в прокси все еще можно вроде, разве нет? То есть это, скорее всего, вызовет просто бугурт, так как чексуммы есть, но осадочек останется.
Принято не значит правильно. Бенчмарки это сферические кони в вакууме, которыми приятно мерятся, но которые очень плохо соотносятся с реальностью. Сколько пишу код, очень часто код упиратся в базу и в том же https://www.techempower.com если глянуть на single/multiply то пора переходить на java/rust. Но даже в этом случае это синтетика, если у вас в коде запрос к БД выполняется 200мс, то влияние от кода и платформы становится довольно незначительным.
Но мы можем попробовать использовать multiprocessing в Python.
А почему не multiprocessing.shared_memory? Даже в доке по python написано, что Manager медленее
Беда в том, что не все функции не блокирующие.
Поправьте меня, если я не прав, но если в том же go взять не pure-go либу то она тоже будет блокирующей, и заблокирует один из воркеров, разве нет?
Больше того, Select в Go еще крут тем, что мы хотим читать сразу из 5 разных потоков.
"Когда у вас в руках молоток, все кажется гвоздями". Но всегда можно взять aiochan.
И в этот момент выясняется, что то, что вы сделаете, может получиться в разы быстрее, чем в библиотеке Python, причём вы не сильно напрягались.
Учитывая, что все эти либы написаны на C или C++, а python выступает просто удобным интерфейсом, потому что его синтаксис несколько проще для всяких казуалов? Не уверен, что будет существенный профит в производительности.
Берём библиотеки Python и выясняем, что мажорная версия ломает обратную совместимость, причем ломает так, что это чинить неоправданно дорого.
Потому что ввели два новых ключевых слова. Изменение имен переменных так неоправданного дорого, что кошмар.
Golang все зависимости складывает в общий кэш для пользователя и там их версианирует, подписывает с ключиками. Можно не бояться того, что мейнтейнер возьмет и перепишет что-нибудь, потому что это будет видно по контрольным суммам.
Думаю, в 2100 Go дойдет до общего регистра пакетов с корпоративным зеркалами, где помимо контрольных сумм еще будет запрещена возможность залить версию пакета повторно.
Кодировки. Это забавная штука, в Go сразу UTF-8, а в Python с 3.7 тоже сразу UTF-8, но на практике не все утилиты/библиотеки об этом догадываются.
Эм… с 3.0 же, или вы о чем?
От блока про туллинг меня, конечно, довольно серьезно бобмит :) Как будто, если программистам не совать в лицо тем, что в языке есть профилирование, они его не будут использовать. Может не в программистах дело?
Ну и вообще, python в основном предлагает вам выбор, хотите, можно построить себе обработку ошибок через монаду Result и общение между корутинами через aiochan и оно все будет довольно просто работать.
Модель же go предлагает вам рабочую лошадку, из которой как только вы начинаете вырастать, язык приходится выкидывать и искать более гибкий язык. А там где "интересные задачи и highload" я так понимаю, из go вырастаю довольно часто :(
имхо True way- валидацию строить вокруг спецификации (например сваггер), но проблема тут в том что нормальных либ на эту тему в Питоне нет. openapi-core — кастрированный вариант того что должно быть: "в Вашем запросе есть ошибка, а где конкретно — не скажу! Расширять format тоже нет возможности, а в остальном, прекрасная маркиза..."
На самом деле, если взять не 0.12.0, а немного старее версию, то там все норм. А в 0.12.0 можно монкипачнуть:
Кастомные форматы от тоже тянет, но не очень очевидно.
Сначала, нужно через custom_formatters параметр передать unmarshal метод, который будет преобразовывать изначальный тип в нужный объект (или просто lambda x: x, если не нужны преобразования) и задать валидатор как тут (раньше можно было декоратором, а теперь автор снова вернул явный словарь).
То есть мне получилось в целом переложить всю валидацию и сериализацию на автоматический код по спеке и это даже работает в проде :) С ответами пока сложнее :(
А как только кто-то один раз сделал шаг влево — то тут же качественный монолит превращается в некачественный и веселуха не заканчивается никогда. В микросервисной архитектуре это сделать практически невозможно. А в силу специфики разработки и того, что в команде, чаще за все, не все опытные разработчики, таких шагов влево делается очень много.
Как раз нет. Монолит качественно написать в разы труднее. Но вот написать абы как проще, это да.
А что делает вызовы из вашего языка в сишные либы? Мне кажется, никакая типизация не спасает от ошибки внутри сишного кода. А рантайм может помочь.
В целом, да, потому что типы не могут гарантировать безопасность. Только рантайм, к сожалению.
Как это может быть потенциально я представляю, но выдвигать такое утверждение и, я так понимаю, на его основании писать статью мне кажется черезмерным.
Это в каком-таком языке? В более-менее популярных остается куча проблем, от вызовов cast и null exception до panic или core dump при использовании сишных либ.
Стандартные проверки еще как работают. Попробуйте себе отправить письмо без правильных подписей в DNS и посмотрите, как оно моментально улетает в спам практически у всех, в том числе у гугла. Мне кажется, лучше говорить, что используются не только стандартные проверки.
Это даст вам возможность проверить утверждения гугла о том, что кандидаты сами виноваты. Потому что, скажем, если совпадение с гуглом будет там 50-70%, то это уже повод для кандидатов задуматся.
А построить регрессию и проанализировать факторы? Или хотя попробовать поднять свой почтовый сервер и настроить стандартные проверки? Сразу как всегда злобная корпорация виновата :(
Особенно, если регулярная рассылка от кандидата один раз из пяти недоходит. Никто ничего не заподозрит, да.
По желанию левой пятки уволить сотрудника, а потом опять выходить на рынок и несколько месяцев искать нового человека, терпя убытки от нереализованных задач. Какой-то странный бизнес.
Эм… а что не так то с "смотри сколько людей это используют"? Мне вот, как программисту такое тоже нравится.
А как бы вы хотели вести разработку, в духе "Просто пиши код"? Когда все просто пилят, пилят, пилят без конца и края?)
Это прям в крупных компаниях. В средних обычно страдания бизнеса выливаются, например, в сокращении расходов на офис (был кулер? Ну, теперь будет фильтр), задержке зарплаты и уменьшение лояльности бизнеса к разработчикам. Потому что цикл обратной связи от владельца бизнеса 2-3 человека и докадывается до всех. Причем самое приятное в этой ситуации то, что как бы вам нужно просто ее перестрадать.
Есть такая штука, называется ответственность. Бывает она, например, перед коллегами или начальством. На словах обычно все как Львы Толстые, а когда доходит до дела, то вспоминаешь, что модуль пилил только ты, он тебе как родной, а задачи на него все приходят и приходят.
А кто же тогда будет делать рутинные задачи? Бедняга, который более уступчивый и в итоге потом тихо уволится? И вот тогда все эти прекрасные задачи свялятся на вас полным скопом и не уверен, что те выиграши в продуктивности, которые были получены окупятся.
Мне интересно, почему как лояльность, так сразу болванчики? Для вас лояльность это что в духе "люби компанию и делай для нее все" или, например, то что начальник более лояльно относится к вашему графику, а вы взамен иногда по 1-2 часа на выходных уделяете работе?
Потому что это скучная монотонная работа (формочка или другая задача, которая занимает кучу времени чисто из-за ее нудности или копание в легаси-части проекта? Потому что вам идеологически не нравится задача? Вариантов на самом деле очень много. Ну и да, причем тут "нравится или нет", если тут скорее вопрос "есть ли компетенция в этой части проекта или нет"? Получается немного подмена понятий.
Почему-то, обычно разработчики страдают от серьезной нагрузки, потому что их модуль никто другой не знает и задачи в нем может пилить только он, а так же от отсутствия отпуска, потому что даже если он в него пошел — баг в его модуле тоже только он может починить. Вообще не знаю никого, кто был бы доволен ситуацией в пункте 2.
Особенно ситуация в пункте 2 выглядит классно, когда разработчик внезапно заболевает, критически важная задача для бизнеса не сделана или критически важная бага не исправлена, а вы понимаете, что заменить разработчика за вменяемый срок (условно, до месяца) вообще некем. В итоге просто все ждут разработчика и страдают.
Вы отрицаете потребность бизнеса в лояльных сотрудниках? Учитывая что лояльность часто формировать дешевле, чем поднимать ЗП, что бы компенсировать ее отсутствие.
Хм… я же правильно понимаю, что это ваш бенч? Если да, то можно исходники?
Нет, там есть select.
Часть старых тулзов, которые еще работают на исключительно python2? Или вы про какие-то другие тулзы?
Поправьте меня, если я не прав, но мне кажется, что на go довольно неудобно будет строить архитектуру отличную от горутины + CSP? Я это имел ввиду под гибкостью.
Ну тогда добро пожаловать в 2100 :) Осталось только порадоваться.
Ну, я же могу в github удалить тег и тегнуть другой коммит? Или прокси навсегда кеширует у себя значение? В таком случае, там хотя бы можно сделать yanked релиз (удалить пакет из прокси)?
Но ведь передеплоить пакет в прокси все еще можно вроде, разве нет? То есть это, скорее всего, вызовет просто бугурт, так как чексуммы есть, но осадочек останется.
Ну, раз вы предлагаете:
Принято не значит правильно. Бенчмарки это сферические кони в вакууме, которыми приятно мерятся, но которые очень плохо соотносятся с реальностью. Сколько пишу код, очень часто код упиратся в базу и в том же https://www.techempower.com если глянуть на single/multiply то пора переходить на java/rust. Но даже в этом случае это синтетика, если у вас в коде запрос к БД выполняется 200мс, то влияние от кода и платформы становится довольно незначительным.
А почему не multiprocessing.shared_memory? Даже в доке по python написано, что Manager медленее
Поправьте меня, если я не прав, но если в том же go взять не pure-go либу то она тоже будет блокирующей, и заблокирует один из воркеров, разве нет?
"Когда у вас в руках молоток, все кажется гвоздями". Но всегда можно взять aiochan.
Учитывая, что все эти либы написаны на C или C++, а python выступает просто удобным интерфейсом, потому что его синтаксис несколько проще для всяких казуалов? Не уверен, что будет существенный профит в производительности.
Потому что ввели два новых ключевых слова. Изменение имен переменных так неоправданного дорого, что кошмар.
Думаю, в 2100 Go дойдет до общего регистра пакетов с корпоративным зеркалами, где помимо контрольных сумм еще будет запрещена возможность залить версию пакета повторно.
Эм… с 3.0 же, или вы о чем?
От блока про туллинг меня, конечно, довольно серьезно бобмит :) Как будто, если программистам не совать в лицо тем, что в языке есть профилирование, они его не будут использовать. Может не в программистах дело?
Ну и вообще, python в основном предлагает вам выбор, хотите, можно построить себе обработку ошибок через монаду Result и общение между корутинами через aiochan и оно все будет довольно просто работать.
Модель же go предлагает вам рабочую лошадку, из которой как только вы начинаете вырастать, язык приходится выкидывать и искать более гибкий язык. А там где "интересные задачи и highload" я так понимаю, из go вырастаю довольно часто :(
На самом деле, если взять не 0.12.0, а немного старее версию, то там все норм. А в 0.12.0 можно монкипачнуть:
Кастомные форматы от тоже тянет, но не очень очевидно.
Сначала, нужно через custom_formatters параметр передать unmarshal метод, который будет преобразовывать изначальный тип в нужный объект (или просто lambda x: x, если не нужны преобразования) и задать валидатор как тут (раньше можно было декоратором, а теперь автор снова вернул явный словарь).
То есть мне получилось в целом переложить всю валидацию и сериализацию на автоматический код по спеке и это даже работает в проде :) С ответами пока сложнее :(
Ставили cups? Мой сетевой принтер он вполне легко подхватил.