Когда мы создаем объекты для классов, требуется память, а атрибут хранится в виде словаря (в dict). В случае, если нам нужно выделить тысячи объектов, это займет достаточно много места в памяти.
В современном Python 3 это неправда уже лет десять, с момента как стали шарить ключи словарей PEP-412
Сегодня использование слотов не имеет особого практического смысла. Даже если у вас получится выиграть пару лишних мегабайт памяти или миллисекунд на обращение к атрибутам, по отношению к полезной нагрузке от тысяч объектов это будет незначительно.
Если у вас полезной нагрузки нет, реально число-дробилка на десятки тысяч объектов и важна производительность, попробуйте “data-driven" подход. Более оптимальные структуры вроде кортежей или условных массивов numpy дадут больше профита, чем "оптимизация" объектов.
Просто автор явно Излучатель, а вы поступили как слишком строгий Растворитель. Помните, что злоупотребление вашей Силой может привести к падению Дома Возможности.
Это потому, что вы понимаете память как справочник.
Но кратковременная память работает, в том числе, как операционные регистры. Без неё вы не сможете сделать хоть сколько-нибудь сложные действия. Например, не сможете анализировать информацию. Ваш мозг просто будет терять начальные данные или их отношения, к моменту аналитических выводов. Никакая ручка и бумага не помогут.
Представьте, как если бы вы писали приложение, которое обращается к базе данных, затем что-то обрабатывает и выдаёт результат. Но регулярно, без каких-либо закономерностей, из случайных переменных эти данные бы пропадали.
Ну кстати, теоретически наверно можно создать информационную систему, которая будет деанонимизировать деньги.
Номера банкнот у нас есть, владельцев кассовых аппаратов и банкоматов можно обязать контролировать поступление и выдачу этих номеров, связывать их с оплачиваемой услугой, через которую иногда можно раскрыть личность (например, при оказании медицинских услуг).
Получается такой граф передачи денег в ограниченном круге лиц. А дальше товарищ майор, так сказать, методами социально-процессуальной инженерии уже идентифицирует владельца денег.
С некоторой уверенностью можно рассчитывать на полную анонимность, если вы реально “отмываете” деньги через цепочку посредников, делаете обработку такого денежного графа нереальной.
А какие проблемы с Docker? Вроде хорошо всё с контейнеризацией.
Есть такой подход, вместо venv или локального Python, в процессе разработки использовать "удаленный" Python. В контексте нашего обсуждения это интерпретатор из Docker образа.
Все зависимости питонячие и системные, включая poetry CLI тогда находятся внутри образа. Значит, чтобы вам обновить pyproject.toml придется вольюмы создавать до хостовых файлов, как-то настраивать команды в своём IDE или через Docker Compose.
Естественно, такая же проблема будет с pip freeze. Я скорее хотел подчеркнуть, что poetry это "CLI-driven" решение, в отличии от pip. Ну или во всяком случае с pip проще работать как с "files-driven" решением.
Сюда же относится проблема с группами зависимостей. Как подсказал alexxxnf выше в poetry можно объявить группы зависимостей, но все они находятся в одном файле pyproject.toml. Это значит что даже если вы распишете установку групп разными шагами в Docker образе, кэш срабатывать не будет. Docker будет определять изменение pyproject.toml и проходить все шаги.
С pip можно разные группы зависимостей оформить в отдельные файлы и юзать кэш Docker по полной. Это вообще не проблема для обычного CRUD API проекта, но если вы работаете с чем-то системным или ML то проблема возникает (пересчёт poetry лок файла или полная установка зависимостей может занимать десятки минут).
Наоборот, проще же. Это просто TOML, его поддержка скоро в стандартной библиотеке Python будет. Можно загрузить с помощью одной из библиотек и работать как со словарём.
Представьте, у вас какой-то CI или дебаг на продакшене, bash и необходимость узнать версию зависимости. В случае pip это будет обычный греп. В случае poetry может быть описание пакета и его версии в несколько строк, это позволяет TOML формат, обработать это чистым bash будет несколько сложнее.
Опять же, поддержка poetry в PyCharm появилась год, может два назад. Наверняка в VSCode она тоже есть. Но в каких-то менее распространённых тулах её нет, зато есть pip.
Если вы решаете задачу обработки в комфортных для себя условиях, конечно, вопрос снимается.
Вообще я не отговариваю использовать Poetry, просто в статье приведены популярные аргументы, основанные на недостатках pip, которые на самом деле неактуальны или возникают из-за неполноты опыта автора.
Мне, например, нравится Poetry тем, что он пытается юзать и развивать предложенный стандарт проектного файла pyproject.toml, с этим в Python исторически всё не очень, в отличии от других языков.
Меня еще раньше удивляли попытки работодателей выторговать меньшую зарплату на испытательный срок. Думаю, неужели для успешной IT компании имеет значение экономия в пару десятков тысяч рублей, пусть даже пару сотен.
А потом узнал, что некоторые начальники так требуют “проявление лояльности” компании. По сути, проверяют кандидата на прогибаемость и неопытность в трудовых отношениях, чтобы в дальнейшем это использовать.
Да, это распространенные аргументы в пользу poetry. Хотелось бы их парировать, не холивара ради, но, чтобы обнадёжить тех, кто не хочет или не может отказаться от pip.
В нашем случае мы не вносили никаких изменений в сам проект, проблему нужно было искать в окружении. Но мы же зафиксировали все версии пакетов?
Мало кто знает, но штатными средствами легко проверить совместимость Python зависимостей через pip check. Как минимум на уровне грамотного CI это не проблема.
Ну и в-третьих, версия пакета может не измениться, а содержимое поменяться кардинально.
Если это реальный вопрос безопасности, эффективнее использовать собственный PyPI индекс. Так вы сможете надёжно проконтролировать содержимое пакетов централизовано, один раз, на все случаи жизни. Следить за тем, чтобы все использовали poetry с проверкой хешей сложнее.
Инструмент предоставляет удобное управление зависимостями
Poetry подразумевает добавление зависимостей только через CLI. Это вызывает трудности если вы пользуетесь виртуализацией, работаете с Python через Docker, например. Со стандартным pip вы можете добавлять зависимости как угодно: руками или средствами вашей IDE.
К тому же автоматизация проще с pip. Например, poetry не умел раньше отдавать версию пакета, а парсить его внутренний формат было гораздо сложнее чем requirements.txt
Разделение зависимостей на зависимости проекта и зависимости разработки
Иногда скоупы зависимостей могут быть сильно сложнее чем зависимости “проекта” и “разработки”. Например, в наукоёмких проектах у вас могут быть тяжелые, но редко обновляемые ML зависимости, отдельно системные, отдельно проектные, и т.д.
Со стандартным pip это легко разбить на отдельные файлы и контролировать время установки. Например, можно использовать кэширование на уровне Docker чтобы каждый раз не переустанавливать вендорные зависимости. Так не получится сделать с poetry, потому что у него один файл конфигурации.
Если в компании не применяются мероприятия по аттестации сотрудника и/или сотрудник не применяет полученные знания в работе, то память тестировщика может очень сильно подвести.
На мой взгляд это деградация процессов. Понятно, что удобнее людей “считать на бумаге” по формальным результатам аттестации, но на качество работы и продукта это никак не повлияет.
Вы не боитесь что сотрудники только и будут, что проходить ваши тесты? Дойдёт до того, что руководители и тимлиды сами будут выдавать правильные ответы своим сотрудникам для повышения общей квалификации команды.
В моей практике самые профессиональные QA были в компании, где на уровне процессов было закреплено, что любая проблема в продакшене — ответственность тестировщиков. Не разработчик “посмотри, что там на проде”, не менеджер “обсуди проблему с аналитиком”, а именно тестировщик ответь пожалуйста почему у нас некачественный продукт.
Конечно, речь не про то, чтобы сделать кого-то крайним. Реальная ответственность и вознаграждение естественным образом стимулирует QA разбираться в технологиях, осваивать новые приемы и повышать свой профессионализм в целом.
Давайте представим, что вы в роли руководителя, вам нужно нанять нового человека в команду. Исходя из того, что сказали комментаторы в этом треде, ценности вашей команды такие:
полное разделение личной и профессиональной жизни
самоотверженность (на работе только работа, никаких личных интересов)
деловая искренность (на работу приходят только ради денег)
здоровый образ жизни (никаких баров)
Можно не задавать никаких вопросов и про ценности не говорить, просто взять человека за его технические навыки. Но представьте, что новый человек реально не попадает в эту команду:
рассказывает о личной жизни
по утрам работает над собственным пет проектом
компанию воспринимает как семью (в жизни нет других друзей)
не против выпить винца в обед, по барам ходит даже в среду
Нужно ли объяснять, что это не просто разность интересов? Это разные подходы к жизни которые наверняка приведут к конфликту и личному дискомфорту всех участников. Вы бы стали как руководитель в таком случае свою команду ограничивать от подобных кандидатов? Стали бы вопросы какие-то задавать на собеседовании кроме технических или как бы вы изменили процесс найма (спойлер, есть и другие прогрессивные способы узнать человека, кроме анкетирования вопросами)?
Как предложил sshmakov, можно прямо эти ценности так списком обозначить и спросить кандидата подходит ему или нет. Не плохой вариант, но очень прямой и не факт, что всем под силу. Можно вопросы наводящие позадавать помягче "каким спортом занимаетесь?" или "готовы за свой счёт разрешать ситуации в личной жизни?" и т.д.
Суть в том, что не существует "правильных" и "не правильных" ценностей. Как неоднократно упоминалось в комментах к этой статье, подобные вопросы — это двунаправленный|обоюдный|взаимный фильтр. С той стороны вопроса сидят живые люди, у которых тоже есть своё представление о жизни. И представьте себе, оно может не совпадать с представлением кандидата. То есть да, это оценка, но оценка относительная а не абсолютная. В интересах обеих сторон выяснить подходите вы друг другу или нет.
Я бы хотел подчеркнуть, что говорю о реальных ценностях команды, то есть о взглядах на жизнь и работу реальных участников этой команды. Речь не идёт про фальшивые "корпоративные ценности", которые заводят ради внешнего бренда компании, и тем более речь не про шаблонные вопросы на скрининге. Не нужно обвинять всех HR и их вопросы в бесполезности. Потому что в любой области, любые вопросы могут быть бесполезными, даже чисто технические, если их задаёт глупый или некомпетентный человек.
А вы сможете сформулировать человеческие ценности в команде? Почему бы их не озвучить и не спросить, все ли вам подходит?
Так своими вопросами компания как раз и обозначает человеческие ценности.
Если вас спрашивают про прочитанную книгу, очевидно, в команде есть человек, который считает чтение книг важной частью саморазвития — одной из человеческих ценностей в команде.
Но для кого-то чтение книг уже архаичный способ саморазвития, предпочтительнее интерактивные и информационные форматы. И в этом прикол. Одни найдут занудного любителя книг, другой найдёт современную команду которым пофиг на книги. Взгляды эти скорей всего будут проецироваться и на технические решения и процессы в команде.
Поэтому я считаю подобные вопросы не плохими, скажем в отличии от “что для вас самое важное в команде”. В моей практике на него практически все отвечают "хорошие процессы". Мысль важная, но информативности не много. Что если в компании не пещерный менеджмент, он понимает важность хороших процессов, осуществляет их и поэтому задумался над комфортом работы команды. Какие вопросы ещё задавать?
Хорошо, по реакции хабра я понял, что вопрос про книгу большинство считает некорректным — дискриминирующим, личным или просто глупым.
А какой вопрос тогда можно задать чтобы узнать человека получше?
Объясню. Ключевая проблема найма — найти сотрудника, который уживется в сложившемся коллективе и сможет решать поставленные задачи. Спрашивать про “сортировку и ООП” не продуктивно — это может освоить любой инженер если понадобится, а профессиональный проходитель интервью заучит уже на третей попытке. Лично я обсуждаю реальные задачи бизнеса на пересечении с опытом кандидата и это в целом помогает понять сможет он решать поставленные задачи или нет. И в принципе я понимаю, что любые не профессиональные вопросы на собеседовании могут выглядеть подозрительно и раздражать. В каком-то смысле даже не прилично спрашивать про интересы человека, с которым ты не знаком.
Но как понять, насколько новый человек разделяет человеческие ценности команды? Какие вопросы задавать? Неужели стандартное “что для вас самое важное в команде” звучит лучше этого несчетного вопроса про книгу?
Вы считаете, что обсуждать книги можно только после работы. А я считаю рассуждения Лема применимыми к решению рабочих задач, а Andrey_Dolg предпочтет людей, осведомлённых в вопросах социальной справедливости.
В конечном итоге наши предпочтения в книгах не помогут решить техническую задачу. Зато сразу дают понять, что построить комфортное сотрудничество нам втроём будет проблематично — не находим общий язык. А значит и совместное решение технических задач будет сложнее из-за слабой коммуникации.
Как по мне, не плохой результат для одного вопроса про книгу в контексте проблемы трудоустройства. Сомневаюсь, что какой-нибудь чисто технический вопрос “Что такое ООП?” или "Как обойти дерево в ширину?" дал бы больше пользы.
Так это вроде не плохой вариант узнать человека получше.
Отгадайте с каким разработчиком вам будет проще решать технические задачи: с тем, кто недавно прочитал книгу Лема "Сумма технологий", или сборник комиксов Ники Водвуд "Пёся".
Мне одному кажется особо циничным писать про выгорания компании, у которой бизнес построен на низкооплачиваемом труде курьеров?
Разрабатывал с нуля складские операции для Самоката, ушёл после того, как бизнес зарезал алгоритм умной консолидации заказов, решив просто оснастить курьеров рюкзаками большего объема. Топы еще ходили по офису и смеялись, что некоторые курьеры с таким рюкзаком падают и не помещаются в лифт. Можно сказать, что я перегорел от осознания негуманности применения своих навыков.
Кажется, что основой для психологического здоровья является уважение к себе, интроспекция, через которую мы можем понять ценности времени и желаний других людей. Сложно перегореть если ты приносишь пользу и счастье окружающим людям, которые отвечают тебе взаимностью.
Однако индивидуальный подход прямо противоречит механизмам и целям коммерческой компании. Скорее компания заинтересована в наборе восстановительных средств и приемов, после которых ты психологически здоровенький снова идешь на конвейер производства. Все разговоры про психологию заканчиваются, как только это касается реальных денег и рабочего времени.
Раз уж вы решили выехать на такой теме, расскажите, на что готова Delivery Club Tech чтобы предотвращать перегорания и поддерживать психологическое здоровье сотрудников в целом. Мои примеры (можете привести свои):
Можете предоставить оплачиваемый отпуск на целый месяц?
Готовы включить в продукт фичи, которые не приносят прибыль, но одобряемы сообществом?
Готовы взять на работу человека на полставки, чтобы он мог заниматься своим хобби в полную силу?
Надеюсь, вы этот вопрос написали истины для, а не потроллить.
Такой статистики, конечно, не существует. Но мы можем сделать статистическое предположение. Предположим, что разработчик в любом случае использует дженерики, реализованные в языке. Даже если он не пишет их в своём коде, опосредованно он всё равно получает пользу от дженериков в стандартной и сторонних библиотеках. Тогда общая популярность языка будет косвенно указывать на эффективность и популярность дженериков.
Возьмем индекс TIOBE и посчитаем популярность языков:
Python + Java + C# + Visual Basic + Swift + PHP = 38% C + JavaScript + ASM + SQL + Go + C++ = 29%
Чисто формально по этим цифрам дженирики наиболее популярный способ даже против суммы всех "не дженериков", а если сравнивать по отдельности, вывод будет еще основательнее.
Я считаю каждый сам должен решать что использовать, зачем, как и вообще на сколько это кому-то нужно. Не нужно постоянно всех отговаривать и тем более пытаться продать "альтернативу, которая вообще лучше".
Давайте предположим, что люди нацелены на добро в первую очередь. Ваш сотрудник или автор статьи в интернете критикует технологии не для того, чтобы ущемить вашу волю и право выбора.
Критик делится собственным опытом решения проблем, часто с помощью альтернатив, чтобы в конечном итоге экономить вам время в поиске истины. Вы ведь не можете лично проверить все технологии на свете.
Касаемо различных технологий из Google, которыми многие пользуются и от которых достаточно много пытаются отговаривать (а это именно так) тоже отдельно хочется сказать.
Часто технологии применяются потому, что они созданы компаниями, считающимися авторитетными. Без каких-либо объективных причин десятки проектов содержат, но не могут использовать эффективно: круглые люки, микросервисы, ангуляры, куберы и т.д.
Критические замечания направлены на разрушение этой апелляции к авторитету, чтобы каждый мог реально сам решить что использовать, на основе объективных аргументов, а не популярности компании изготовителя.
Особенно это актуально для разработчиков, которые занимают рядовые позиции и вынуждены работать с тем, что им спускают архитекторы и технические директора, которые эмоционально оценивают своё производство на уровне гугла, амазона или фейсбука.
Понимаю, о чем вы говорите. Несовершенство информационных технологий часто увеличивает видимость ложных ценностей и оставляет в тени реальные достижения.
Но авторитеты вроде Google вкладывают достаточно средств для создания хайпа и рекламы собственных технологий, чтобы закрепить выгодные им тенденции в культуре разработки даже в ущерб реальному технологическому прогрессу.
Молчание в такой ситуации — не лучшая стратегия. Наоборот, конструктивная критика только и остается для реального продвижения и разрушения ложных ориентиров.
Противостояние Rust и Go в подобных статьях и комментариях не случайно. Хотя Rust предлагает реальные инновации в программировании, он вынужден отыгрываться на втором плане из-за рекламно успешного, но технически посредственного Go.
Обобщение в широком смысле слова — это ключевая аналитическая задача программиста в процессе разработки решения и моделирования предметной области.
Конкретно дженерики — наиболее популярный и эффективный способ реализовать обобщенное программирование на строго типизированных языках, как показал опыт. Настолько эффективный, что даже языки с динамической типизацией вроде Python пытаются притащить дженерики в свое окружение. Нужно пояснять в чем ирония?
Кроме технической составляющей, я бы еще отметил, что адепты Go все эти 12 лет себя и окружающих фанатично убеждали что дженерики не нужны "by design". Однако, реальная практика всё же вынудила признать некомпетентность изначальных идей.
Этот пример с дженериками достаточно очевидный и показательный чтобы отметить в целом всю несостоятельность и глупость дизайна Go. Поэтому используется такая фраза как "этим всё сказано".
- В споре рождается истина... - Что ты, Сократ, не надо! Спорить с богами бессмысленно, выпей-ка лучше яду!
(с) Ф. Кривин
На мой взгляд, критическая статья прекрасный способ повлиять на сложившуюся ситуацию, с которой ты не согласен. Вы знаете какие-то еще цивилизованные способы?
Однажды я участвовал во встрече по обсуждению крупной фичи, и половину времени, отведённого на обсуждение, мы выбирали цвет кнопки на одном из экранов.
Закон тривиальности, на мой взгляд, первопричина неэффективности современной разработки. Логично что участники встречи сводят обсуждение до наиболее понятного общего уровня, невозможно дискутировать о том, чего не знаешь.
Но неверное толкование гибких методологий, которое исключает проектирование и анализ, превращает большинство обсуждений буквально в цирк: один рассказывает истории из жизни, другой гадает и говорит как ему кажется, третий поддакивает наиболее простым соображениям.
В своей практике придерживаюсь некоторых правил, чтобы справиться с этой проблемой:
Обсуждение ведётся в формате ответов на вопросы, указанных в агенде
Перед встречей всем выделяется время для подготовки
На встречу допускаются только участники с требованиями или результатами анализа
Просто прийти “обсудить” или "послушать" нельзя, даже если это менеджер
Ведущий может закончить встречу в любой момент, если правила выше не выполняются во избежание лишней траты времени
В современном Python 3 это неправда уже лет десять, с момента как стали шарить ключи словарей PEP-412
Сегодня использование слотов не имеет особого практического смысла. Даже если у вас получится выиграть пару лишних мегабайт памяти или миллисекунд на обращение к атрибутам, по отношению к полезной нагрузке от тысяч объектов это будет незначительно.
Если у вас полезной нагрузки нет, реально число-дробилка на десятки тысяч объектов и важна производительность, попробуйте “data-driven" подход. Более оптимальные структуры вроде кортежей или условных массивов numpy дадут больше профита, чем "оптимизация" объектов.
Просто автор явно Излучатель, а вы поступили как слишком строгий Растворитель. Помните, что злоупотребление вашей Силой может привести к падению Дома Возможности.
Это потому, что вы понимаете память как справочник.
Но кратковременная память работает, в том числе, как операционные регистры. Без неё вы не сможете сделать хоть сколько-нибудь сложные действия. Например, не сможете анализировать информацию. Ваш мозг просто будет терять начальные данные или их отношения, к моменту аналитических выводов. Никакая ручка и бумага не помогут.
Представьте, как если бы вы писали приложение, которое обращается к базе данных, затем что-то обрабатывает и выдаёт результат. Но регулярно, без каких-либо закономерностей, из случайных переменных эти данные бы пропадали.
Ну кстати, теоретически наверно можно создать информационную систему, которая будет деанонимизировать деньги.
Номера банкнот у нас есть, владельцев кассовых аппаратов и банкоматов можно обязать контролировать поступление и выдачу этих номеров, связывать их с оплачиваемой услугой, через которую иногда можно раскрыть личность (например, при оказании медицинских услуг).
Получается такой граф передачи денег в ограниченном круге лиц. А дальше товарищ майор, так сказать, методами социально-процессуальной инженерии уже идентифицирует владельца денег.
С некоторой уверенностью можно рассчитывать на полную анонимность, если вы реально “отмываете” деньги через цепочку посредников, делаете обработку такого денежного графа нереальной.
Есть такой подход, вместо venv или локального Python, в процессе разработки использовать "удаленный" Python. В контексте нашего обсуждения это интерпретатор из Docker образа.
Все зависимости питонячие и системные, включая poetry CLI тогда находятся внутри образа. Значит, чтобы вам обновить pyproject.toml придется вольюмы создавать до хостовых файлов, как-то настраивать команды в своём IDE или через Docker Compose.
Естественно, такая же проблема будет с pip freeze. Я скорее хотел подчеркнуть, что poetry это "CLI-driven" решение, в отличии от pip. Ну или во всяком случае с pip проще работать как с "files-driven" решением.
Сюда же относится проблема с группами зависимостей. Как подсказал alexxxnf выше в poetry можно объявить группы зависимостей, но все они находятся в одном файле pyproject.toml. Это значит что даже если вы распишете установку групп разными шагами в Docker образе, кэш срабатывать не будет. Docker будет определять изменение pyproject.toml и проходить все шаги.
С pip можно разные группы зависимостей оформить в отдельные файлы и юзать кэш Docker по полной. Это вообще не проблема для обычного CRUD API проекта, но если вы работаете с чем-то системным или ML то проблема возникает (пересчёт poetry лок файла или полная установка зависимостей может занимать десятки минут).
Представьте, у вас какой-то CI или дебаг на продакшене, bash и необходимость узнать версию зависимости. В случае pip это будет обычный греп. В случае poetry может быть описание пакета и его версии в несколько строк, это позволяет TOML формат, обработать это чистым bash будет несколько сложнее.
Опять же, поддержка poetry в PyCharm появилась год, может два назад. Наверняка в VSCode она тоже есть. Но в каких-то менее распространённых тулах её нет, зато есть pip.
Если вы решаете задачу обработки в комфортных для себя условиях, конечно, вопрос снимается.
Вообще я не отговариваю использовать Poetry, просто в статье приведены популярные аргументы, основанные на недостатках pip, которые на самом деле неактуальны или возникают из-за неполноты опыта автора.
Мне, например, нравится Poetry тем, что он пытается юзать и развивать предложенный стандарт проектного файла pyproject.toml, с этим в Python исторически всё не очень, в отличии от других языков.
Меня еще раньше удивляли попытки работодателей выторговать меньшую зарплату на испытательный срок. Думаю, неужели для успешной IT компании имеет значение экономия в пару десятков тысяч рублей, пусть даже пару сотен.
А потом узнал, что некоторые начальники так требуют “проявление лояльности” компании. По сути, проверяют кандидата на прогибаемость и неопытность в трудовых отношениях, чтобы в дальнейшем это использовать.
Да, это распространенные аргументы в пользу poetry. Хотелось бы их парировать, не холивара ради, но, чтобы обнадёжить тех, кто не хочет или не может отказаться от pip.
Мало кто знает, но штатными средствами легко проверить совместимость Python зависимостей через pip check. Как минимум на уровне грамотного CI это не проблема.
Если это реальный вопрос безопасности, эффективнее использовать собственный PyPI индекс. Так вы сможете надёжно проконтролировать содержимое пакетов централизовано, один раз, на все случаи жизни. Следить за тем, чтобы все использовали poetry с проверкой хешей сложнее.
Poetry подразумевает добавление зависимостей только через CLI. Это вызывает трудности если вы пользуетесь виртуализацией, работаете с Python через Docker, например. Со стандартным pip вы можете добавлять зависимости как угодно: руками или средствами вашей IDE.
К тому же автоматизация проще с pip. Например, poetry не умел раньше отдавать версию пакета, а парсить его внутренний формат было гораздо сложнее чем requirements.txt
Иногда скоупы зависимостей могут быть сильно сложнее чем зависимости “проекта” и “разработки”. Например, в наукоёмких проектах у вас могут быть тяжелые, но редко обновляемые ML зависимости, отдельно системные, отдельно проектные, и т.д.
Со стандартным pip это легко разбить на отдельные файлы и контролировать время установки. Например, можно использовать кэширование на уровне Docker чтобы каждый раз не переустанавливать вендорные зависимости. Так не получится сделать с poetry, потому что у него один файл конфигурации.
На мой взгляд это деградация процессов. Понятно, что удобнее людей “считать на бумаге” по формальным результатам аттестации, но на качество работы и продукта это никак не повлияет.
Вы не боитесь что сотрудники только и будут, что проходить ваши тесты? Дойдёт до того, что руководители и тимлиды сами будут выдавать правильные ответы своим сотрудникам для повышения общей квалификации команды.
В моей практике самые профессиональные QA были в компании, где на уровне процессов было закреплено, что любая проблема в продакшене — ответственность тестировщиков. Не разработчик “посмотри, что там на проде”, не менеджер “обсуди проблему с аналитиком”, а именно тестировщик ответь пожалуйста почему у нас некачественный продукт.
Конечно, речь не про то, чтобы сделать кого-то крайним. Реальная ответственность и вознаграждение естественным образом стимулирует QA разбираться в технологиях, осваивать новые приемы и повышать свой профессионализм в целом.
Давайте представим, что вы в роли руководителя, вам нужно нанять нового человека в команду. Исходя из того, что сказали комментаторы в этом треде, ценности вашей команды такие:
полное разделение личной и профессиональной жизни
самоотверженность (на работе только работа, никаких личных интересов)
деловая искренность (на работу приходят только ради денег)
здоровый образ жизни (никаких баров)
Можно не задавать никаких вопросов и про ценности не говорить, просто взять человека за его технические навыки. Но представьте, что новый человек реально не попадает в эту команду:
рассказывает о личной жизни
по утрам работает над собственным пет проектом
компанию воспринимает как семью (в жизни нет других друзей)
не против выпить винца в обед, по барам ходит даже в среду
Нужно ли объяснять, что это не просто разность интересов? Это разные подходы к жизни которые наверняка приведут к конфликту и личному дискомфорту всех участников. Вы бы стали как руководитель в таком случае свою команду ограничивать от подобных кандидатов? Стали бы вопросы какие-то задавать на собеседовании кроме технических или как бы вы изменили процесс найма (спойлер, есть и другие прогрессивные способы узнать человека, кроме анкетирования вопросами)?
Как предложил sshmakov, можно прямо эти ценности так списком обозначить и спросить кандидата подходит ему или нет. Не плохой вариант, но очень прямой и не факт, что всем под силу. Можно вопросы наводящие позадавать помягче "каким спортом занимаетесь?" или "готовы за свой счёт разрешать ситуации в личной жизни?" и т.д.
Суть в том, что не существует "правильных" и "не правильных" ценностей. Как неоднократно упоминалось в комментах к этой статье, подобные вопросы — это двунаправленный|обоюдный|взаимный фильтр. С той стороны вопроса сидят живые люди, у которых тоже есть своё представление о жизни. И представьте себе, оно может не совпадать с представлением кандидата. То есть да, это оценка, но оценка относительная а не абсолютная. В интересах обеих сторон выяснить подходите вы друг другу или нет.
Я бы хотел подчеркнуть, что говорю о реальных ценностях команды, то есть о взглядах на жизнь и работу реальных участников этой команды. Речь не идёт про фальшивые "корпоративные ценности", которые заводят ради внешнего бренда компании, и тем более речь не про шаблонные вопросы на скрининге. Не нужно обвинять всех HR и их вопросы в бесполезности. Потому что в любой области, любые вопросы могут быть бесполезными, даже чисто технические, если их задаёт глупый или некомпетентный человек.
Так своими вопросами компания как раз и обозначает человеческие ценности.
Если вас спрашивают про прочитанную книгу, очевидно, в команде есть человек, который считает чтение книг важной частью саморазвития — одной из человеческих ценностей в команде.
Но для кого-то чтение книг уже архаичный способ саморазвития, предпочтительнее интерактивные и информационные форматы. И в этом прикол. Одни найдут занудного любителя книг, другой найдёт современную команду которым пофиг на книги. Взгляды эти скорей всего будут проецироваться и на технические решения и процессы в команде.
Поэтому я считаю подобные вопросы не плохими, скажем в отличии от “что для вас самое важное в команде”. В моей практике на него практически все отвечают "хорошие процессы". Мысль важная, но информативности не много. Что если в компании не пещерный менеджмент, он понимает важность хороших процессов, осуществляет их и поэтому задумался над комфортом работы команды. Какие вопросы ещё задавать?
Хорошо, по реакции хабра я понял, что вопрос про книгу большинство считает некорректным — дискриминирующим, личным или просто глупым.
А какой вопрос тогда можно задать чтобы узнать человека получше?
Объясню. Ключевая проблема найма — найти сотрудника, который уживется в сложившемся коллективе и сможет решать поставленные задачи. Спрашивать про “сортировку и ООП” не продуктивно — это может освоить любой инженер если понадобится, а профессиональный проходитель интервью заучит уже на третей попытке. Лично я обсуждаю реальные задачи бизнеса на пересечении с опытом кандидата и это в целом помогает понять сможет он решать поставленные задачи или нет. И в принципе я понимаю, что любые не профессиональные вопросы на собеседовании могут выглядеть подозрительно и раздражать. В каком-то смысле даже не прилично спрашивать про интересы человека, с которым ты не знаком.
Но как понять, насколько новый человек разделяет человеческие ценности команды? Какие вопросы задавать? Неужели стандартное “что для вас самое важное в команде” звучит лучше этого несчетного вопроса про книгу?
Вы считаете, что обсуждать книги можно только после работы. А я считаю рассуждения Лема применимыми к решению рабочих задач, а Andrey_Dolg предпочтет людей, осведомлённых в вопросах социальной справедливости.
В конечном итоге наши предпочтения в книгах не помогут решить техническую задачу. Зато сразу дают понять, что построить комфортное сотрудничество нам втроём будет проблематично — не находим общий язык. А значит и совместное решение технических задач будет сложнее из-за слабой коммуникации.
Как по мне, не плохой результат для одного вопроса про книгу в контексте проблемы трудоустройства. Сомневаюсь, что какой-нибудь чисто технический вопрос “Что такое ООП?” или "Как обойти дерево в ширину?" дал бы больше пользы.
Так это вроде не плохой вариант узнать человека получше.
Отгадайте с каким разработчиком вам будет проще решать технические задачи: с тем, кто недавно прочитал книгу Лема "Сумма технологий", или сборник комиксов Ники Водвуд "Пёся".
Мне одному кажется особо циничным писать про выгорания компании, у которой бизнес построен на низкооплачиваемом труде курьеров?
Разрабатывал с нуля складские операции для Самоката, ушёл после того, как бизнес зарезал алгоритм умной консолидации заказов, решив просто оснастить курьеров рюкзаками большего объема. Топы еще ходили по офису и смеялись, что некоторые курьеры с таким рюкзаком падают и не помещаются в лифт. Можно сказать, что я перегорел от осознания негуманности применения своих навыков.
Кажется, что основой для психологического здоровья является уважение к себе, интроспекция, через которую мы можем понять ценности времени и желаний других людей. Сложно перегореть если ты приносишь пользу и счастье окружающим людям, которые отвечают тебе взаимностью.
Однако индивидуальный подход прямо противоречит механизмам и целям коммерческой компании. Скорее компания заинтересована в наборе восстановительных средств и приемов, после которых ты психологически здоровенький снова идешь на конвейер производства. Все разговоры про психологию заканчиваются, как только это касается реальных денег и рабочего времени.
Раз уж вы решили выехать на такой теме, расскажите, на что готова Delivery Club Tech чтобы предотвращать перегорания и поддерживать психологическое здоровье сотрудников в целом. Мои примеры (можете привести свои):
Можете предоставить оплачиваемый отпуск на целый месяц?
Готовы включить в продукт фичи, которые не приносят прибыль, но одобряемы сообществом?
Готовы взять на работу человека на полставки, чтобы он мог заниматься своим хобби в полную силу?
Надеюсь, вы этот вопрос написали истины для, а не потроллить.
Такой статистики, конечно, не существует. Но мы можем сделать статистическое предположение. Предположим, что разработчик в любом случае использует дженерики, реализованные в языке. Даже если он не пишет их в своём коде, опосредованно он всё равно получает пользу от дженериков в стандартной и сторонних библиотеках. Тогда общая популярность языка будет косвенно указывать на эффективность и популярность дженериков.
Возьмем индекс TIOBE и посчитаем популярность языков:
Чисто формально по этим цифрам дженирики наиболее популярный способ даже против суммы всех "не дженериков", а если сравнивать по отдельности, вывод будет еще основательнее.
Давайте предположим, что люди нацелены на добро в первую очередь. Ваш сотрудник или автор статьи в интернете критикует технологии не для того, чтобы ущемить вашу волю и право выбора.
Критик делится собственным опытом решения проблем, часто с помощью альтернатив, чтобы в конечном итоге экономить вам время в поиске истины. Вы ведь не можете лично проверить все технологии на свете.
Часто технологии применяются потому, что они созданы компаниями, считающимися авторитетными. Без каких-либо объективных причин десятки проектов содержат, но не могут использовать эффективно: круглые люки, микросервисы, ангуляры, куберы и т.д.
Критические замечания направлены на разрушение этой апелляции к авторитету, чтобы каждый мог реально сам решить что использовать, на основе объективных аргументов, а не популярности компании изготовителя.
Особенно это актуально для разработчиков, которые занимают рядовые позиции и вынуждены работать с тем, что им спускают архитекторы и технические директора, которые эмоционально оценивают своё производство на уровне гугла, амазона или фейсбука.
Понимаю, о чем вы говорите. Несовершенство информационных технологий часто увеличивает видимость ложных ценностей и оставляет в тени реальные достижения.
Но авторитеты вроде Google вкладывают достаточно средств для создания хайпа и рекламы собственных технологий, чтобы закрепить выгодные им тенденции в культуре разработки даже в ущерб реальному технологическому прогрессу.
Молчание в такой ситуации — не лучшая стратегия. Наоборот, конструктивная критика только и остается для реального продвижения и разрушения ложных ориентиров.
Противостояние Rust и Go в подобных статьях и комментариях не случайно. Хотя Rust предлагает реальные инновации в программировании, он вынужден отыгрываться на втором плане из-за рекламно успешного, но технически посредственного Go.
Обобщение в широком смысле слова — это ключевая аналитическая задача программиста в процессе разработки решения и моделирования предметной области.
Конкретно дженерики — наиболее популярный и эффективный способ реализовать обобщенное программирование на строго типизированных языках, как показал опыт. Настолько эффективный, что даже языки с динамической типизацией вроде Python пытаются притащить дженерики в свое окружение. Нужно пояснять в чем ирония?
Кроме технической составляющей, я бы еще отметил, что адепты Go все эти 12 лет себя и окружающих фанатично убеждали что дженерики не нужны "by design". Однако, реальная практика всё же вынудила признать некомпетентность изначальных идей.
Этот пример с дженериками достаточно очевидный и показательный чтобы отметить в целом всю несостоятельность и глупость дизайна Go. Поэтому используется такая фраза как "этим всё сказано".
Ваш капитан очевидность.
(с) Ф. Кривин
На мой взгляд, критическая статья прекрасный способ повлиять на сложившуюся ситуацию, с которой ты не согласен. Вы знаете какие-то еще цивилизованные способы?
Закон тривиальности, на мой взгляд, первопричина неэффективности современной разработки. Логично что участники встречи сводят обсуждение до наиболее понятного общего уровня, невозможно дискутировать о том, чего не знаешь.
Но неверное толкование гибких методологий, которое исключает проектирование и анализ, превращает большинство обсуждений буквально в цирк: один рассказывает истории из жизни, другой гадает и говорит как ему кажется, третий поддакивает наиболее простым соображениям.
В своей практике придерживаюсь некоторых правил, чтобы справиться с этой проблемой:
Обсуждение ведётся в формате ответов на вопросы, указанных в агенде
Перед встречей всем выделяется время для подготовки
На встречу допускаются только участники с требованиями или результатами анализа
Просто прийти “обсудить” или "послушать" нельзя, даже если это менеджер
Ведущий может закончить встречу в любой момент, если правила выше не выполняются во избежание лишней траты времени