Благодарю, ваш результат впечатляет! В целом код написан весьма элегантно. Помимо вашей сложности, отдельно отмечу ваши заслуги в достижении ограничения рекурсивных вызовов.
Что это за руководство, если у него возникают такие вопросы, — школьники стартаперы? Или человек, который исправил баг, единственный, кто разбирается в том, что он делает в компании?
Все ваши вопросы — это жалкая попытка оправдать тупые тайм-трекеры, несмотря на то, что вас заминусовали еще в начале дискуссии. Вам уже привели вполне вменяемые доводы против, а вы уперто стоите на своем. Боюсь, что, с этой точки зрения, вам уже никакие доводы не помогут. Поэтому, не вижу смысла вести с вами дальнейшую дискуссию.
Желаю вам расти над собой, углублять свои знания — без них невозможно контролировать и выстраивать бизнес-процессы. Может быть тогда, вы поймёте, что тайм-трекеры хороши исключительно для вас как оправдание ваших слабостей в тех или иных аспектах менеджмента, но не для квалифицированных разработчиков, которые, убегут от тайм-трекеров при первой же возможности.
Все мои комментарии написаны как оппозиция к тайм-трекенгу в пользу системы контроля версий в контексте обсуждаемой статьи. Если вы в них не видите определенной позиции, то я могу лишь посочувствовать вашим аналитическим способностям.
Показатели системы контроля версий как-то не понятно как использовать. Кто-то багу чинит и за месяц одну строку меняет и его увольняют/депремируют на основании показателей контроля версий.
Почему непонятно? Зачем увольнять? Неужели сложно оценить, что человек одной строчкой исправил баг? А если этот баг критический, то это только повышает ценность сотрудника несмотря на время, затраченное на исправление бага.
Если такого разработчика увольняют, то, опять же, вопрос к адекватности руководства.
Скорость исполнения, тесты, документирование, шаблоны проектирования, дизайн классов. Неужели трудно отличить код человека с опытом от кода некомпетентного сотрудника, вчерашнего выпускника, индуса?
Подозреваю, что менеджеру — трудно. Поэтому проще тайм-трекеры. Вот только не нужно оправдывать некомпетентность менеджеров и руководителей использованием тайм-трекеров.
Ну, кто-то работает на двух или трёх работах, а я на одной. Нахрена мне тайм-трекер? То, что гитлаб и много кто ещё используют тайм-трекеры, не означает, что их приветствуют все разработчики, и тем более, что они эффективней показателей системы контроля версий. Честно говоря, в моих глазах этот факт не красит гитлаб, который сам по себе является системой контроля версий.
Если менеджменту чхать на разработчиков, то да, тайм-трекеры — это круто, а для меня, как для разработчика, тайм-трекеры — идиотская система отслеживания сотрудников жлобским руководством.
Это ещё цветочки, я как-то обсуждал тестирование с одним менеджером, и он думал, что тестирование — это открыть в браузере dev-версию веб приложения, потыкать на кнопки и всё, можно в прод)
А как соотносятся повышение показателей своего труда и накрутка своей стастики через бессмысленные коммиты?
Есть вполне конкретные критерии оценки качества кода, по которым и нужно оценивать показатели труда отдельных членов команды. Что с ними делать потом — другой вопрос — это зависит практик компании. Можно не увольнять, а предоставить им ментора, например, но я бы уволил за сам факт накрутки.
Если хочешь повысить свои показатели — делай это честным трудом, а не имитацией и обманом, а лучше не лезь туда, где ты некомпетентен.
Более того, адекватный менеджмент не наймет таких людей в свою команду.
Я не понимаю, почему меня должно волновать субъективное мнение команды тогда, как мою работу можно оценить по коммитам? А если задача застревает на отдельных звеньях команды, то причем тут я? Нет коммитов — не было задач.
люди начнут накручивать статистику в этой системе контроля версий
Вы всерьез полагаете, что такие прецеденты трудно заметить? Наоборот, это хорошо покажет недобросовестных сотрудников, от которых нужно избавиться сразу.
Я бы не хотел зависить от мнения условного дизайнера, который ничего не понимает в специфике моей работы. И, честно говоря, я сильно сомневаюсь в способности людей давать адекватную, непредвзятую оценку.
Вы уверены? Прям таки вижу как удаленные разработчики Amazon или Google «сидят под трекерами» без доли смущения.
Трекеры унижают достоинство трудящихся, я считаю их использование неэтичным.
Лично я не стану работать на идиотов, которые считают допустимым использовать тайм-трекеры для подсчёта зарплаты сотрудников. Я получаю деньги за свои профессиональные навыки и знания, применение которых и так включает время, затраченное на разработку продукта.
Не надо оправдывать жлобов, которые хотят получить продукт при минимальных вложениях. Как правило, у них работает низкоквалифицированный персонал.
Самое идиотское — это трекеры времени и списки задач. Когда меня попросили поставить тайм-трекер, я всерьез задумался об уходе из компании. Списки задач для домохозяек ещё терпимо, но трекеры свидетельствуют об общем низком уровне сотрудников компании, раз приходится таким идиотским способом за ними следить. Самый лучший подход — это статистика аккаунта в системе контроля версий, по которой видно вклад каждого отдельного участника на разных временных интервалах. Другое дело, что менеджмент не всегда знает о существовании системы контроля версий, не говоря уже о том, что утруждает себя зарегистрироваться в ней и отслеживать статистику коммитов и прочее. Наболело...
По поводу архитектуры: насколько я понимаю, опять же, из документации, сервер — многопроцессорный из коробки. То есть, для сервера не имеет значения сколько к нему обращается «клиентов», для него это все выглядит как просто запросы от процессов по IPC. При этом, серверу, чтобы обслужить запрос, достаточно чтобы у клиентского процесса (который обращается к нему в данный момент времени) совпал ключ аутентификации (если она используется).
Касательно конкретно моей архитектуры: мне не нужно много процессов — один сервер в руте и управляющий процесс на стороне пользователя. Однако это не мешает расширить функциональность до многопроцессорности, только реализация обработки запросов по API при этом изменится.
Вы правы — даже мой линтер жаловался на Unbound Variable. И с контекстным менеджером тоже глупо получилось.
В защиту курса философии хочу сказать, что Computer Science оперирует философскими категориями, например, сущность, объект и так далее. Ближе к программированию – математика, также не лишена подобных категорий: бесконечность, множество. Кроме привычной дискретной математики, есть другие разделы, например, теория категорий, которая связана с функциональным программированием. Исследование отношений между математическими объектами наверняка опирается на методологию философии. Иначе мне сложно представить.
Если человек после вуза неспособен оперировать философскими категориями в процессе мышления, сюда же входит близкая к программированию и математике логика, то он не будет способен строить системы и решать концептуальные вопросы этих систем, не говор уже о том, что, не зря ли он учился...
Автор писал о профессионализме, оспаривая, в том числе, присутствие философии в программе обучения. Я думаю, что самая минимальная подготовка по курсу философии вполне себе входит в список компетенций «профессионала».
К сожалению, вузы в большинстве своём выпускают людей, которые неспособны обучаться самостоятельно, и в этом самая главная проблема. В лучшем случае они умеют работать со стандартизированными протоколами.
Я преподавал программирование подросткам, поэтому мои оценки в отношении выпускников ВУЗов могут быть субъективными.
Благодарю, ваш результат впечатляет! В целом код написан весьма элегантно. Помимо вашей сложности, отдельно отмечу ваши заслуги в достижении ограничения рекурсивных вызовов.
Сочувствую
Ждали n**3
Спасибо! Конечно, n — это не номер ряда, передаваемый в функцию, а общее число итераций при образующейся последовательности.
😅
Что это за руководство, если у него возникают такие вопросы, — школьники стартаперы? Или человек, который исправил баг, единственный, кто разбирается в том, что он делает в компании?
Все ваши вопросы — это жалкая попытка оправдать тупые тайм-трекеры, несмотря на то, что вас заминусовали еще в начале дискуссии. Вам уже привели вполне вменяемые доводы против, а вы уперто стоите на своем. Боюсь, что, с этой точки зрения, вам уже никакие доводы не помогут. Поэтому, не вижу смысла вести с вами дальнейшую дискуссию.
Желаю вам расти над собой, углублять свои знания — без них невозможно контролировать и выстраивать бизнес-процессы. Может быть тогда, вы поймёте, что тайм-трекеры хороши исключительно для вас как оправдание ваших слабостей в тех или иных аспектах менеджмента, но не для квалифицированных разработчиков, которые, убегут от тайм-трекеров при первой же возможности.
Все мои комментарии написаны как оппозиция к тайм-трекенгу в пользу системы контроля версий в контексте обсуждаемой статьи. Если вы в них не видите определенной позиции, то я могу лишь посочувствовать вашим аналитическим способностям.
Серьезно? Спасибо что просветили. Вы лучше это объясните заминусованному товарищу выше.
Почему не осуществимо? А для чего существует code review? Для чего придумали merge request?
Почему непонятно? Зачем увольнять? Неужели сложно оценить, что человек одной строчкой исправил баг? А если этот баг критический, то это только повышает ценность сотрудника несмотря на время, затраченное на исправление бага.
Если такого разработчика увольняют, то, опять же, вопрос к адекватности руководства.
Скорость исполнения, тесты, документирование, шаблоны проектирования, дизайн классов. Неужели трудно отличить код человека с опытом от кода некомпетентного сотрудника, вчерашнего выпускника, индуса?
Подозреваю, что менеджеру — трудно. Поэтому проще тайм-трекеры. Вот только не нужно оправдывать некомпетентность менеджеров и руководителей использованием тайм-трекеров.
Ну, кто-то работает на двух или трёх работах, а я на одной. Нахрена мне тайм-трекер? То, что гитлаб и много кто ещё используют тайм-трекеры, не означает, что их приветствуют все разработчики, и тем более, что они эффективней показателей системы контроля версий. Честно говоря, в моих глазах этот факт не красит гитлаб, который сам по себе является системой контроля версий.
Если менеджменту чхать на разработчиков, то да, тайм-трекеры — это круто, а для меня, как для разработчика, тайм-трекеры — идиотская система отслеживания сотрудников жлобским руководством.
Это ещё цветочки, я как-то обсуждал тестирование с одним менеджером, и он думал, что тестирование — это открыть в браузере dev-версию веб приложения, потыкать на кнопки и всё, можно в прод)
А как соотносятся повышение показателей своего труда и накрутка своей стастики через бессмысленные коммиты?
Есть вполне конкретные критерии оценки качества кода, по которым и нужно оценивать показатели труда отдельных членов команды. Что с ними делать потом — другой вопрос — это зависит практик компании. Можно не увольнять, а предоставить им ментора, например, но я бы уволил за сам факт накрутки.
Если хочешь повысить свои показатели — делай это честным трудом, а не имитацией и обманом, а лучше не лезь туда, где ты некомпетентен.
Более того, адекватный менеджмент не наймет таких людей в свою команду.
Я не понимаю, почему меня должно волновать субъективное мнение команды тогда, как мою работу можно оценить по коммитам? А если задача застревает на отдельных звеньях команды, то причем тут я? Нет коммитов — не было задач.
Вы всерьез полагаете, что такие прецеденты трудно заметить? Наоборот, это хорошо покажет недобросовестных сотрудников, от которых нужно избавиться сразу.
Я бы не хотел зависить от мнения условного дизайнера, который ничего не понимает в специфике моей работы. И, честно говоря, я сильно сомневаюсь в способности людей давать адекватную, непредвзятую оценку.
Вы уверены? Прям таки вижу как удаленные разработчики Amazon или Google «сидят под трекерами» без доли смущения.
Трекеры унижают достоинство трудящихся, я считаю их использование неэтичным.
Лично я не стану работать на идиотов, которые считают допустимым использовать тайм-трекеры для подсчёта зарплаты сотрудников. Я получаю деньги за свои профессиональные навыки и знания, применение которых и так включает время, затраченное на разработку продукта.
Не надо оправдывать жлобов, которые хотят получить продукт при минимальных вложениях. Как правило, у них работает низкоквалифицированный персонал.
Самое идиотское — это трекеры времени и списки задач. Когда меня попросили поставить тайм-трекер, я всерьез задумался об уходе из компании. Списки задач для домохозяек ещё терпимо, но трекеры свидетельствуют об общем низком уровне сотрудников компании, раз приходится таким идиотским способом за ними следить. Самый лучший подход — это статистика аккаунта в системе контроля версий, по которой видно вклад каждого отдельного участника на разных временных интервалах. Другое дело, что менеджмент не всегда знает о существовании системы контроля версий, не говоря уже о том, что утруждает себя зарегистрироваться в ней и отслеживать статистику коммитов и прочее. Наболело...
Начну с конца.
По поводу безопасности: в моем приложении реализована аутентификация клиента по hmac. В статье этого нет, потому что на тот момент не было и в коде. Если интересно, подробности есть в документации: https://docs.python.org/3/library/multiprocessing.html#authentication-keys
По поводу архитектуры: насколько я понимаю, опять же, из документации, сервер — многопроцессорный из коробки. То есть, для сервера не имеет значения сколько к нему обращается «клиентов», для него это все выглядит как просто запросы от процессов по IPC. При этом, серверу, чтобы обслужить запрос, достаточно чтобы у клиентского процесса (который обращается к нему в данный момент времени) совпал ключ аутентификации (если она используется).
Касательно конкретно моей архитектуры: мне не нужно много процессов — один сервер в руте и управляющий процесс на стороне пользователя. Однако это не мешает расширить функциональность до многопроцессорности, только реализация обработки запросов по API при этом изменится.
Вы правы — даже мой линтер жаловался на Unbound Variable. И с контекстным менеджером тоже глупо получилось.
Спасибо за замечания.
В защиту курса философии хочу сказать, что Computer Science оперирует философскими категориями, например, сущность, объект и так далее. Ближе к программированию – математика, также не лишена подобных категорий: бесконечность, множество. Кроме привычной дискретной математики, есть другие разделы, например, теория категорий, которая связана с функциональным программированием. Исследование отношений между математическими объектами наверняка опирается на методологию философии. Иначе мне сложно представить.
Если человек после вуза неспособен оперировать философскими категориями в процессе мышления, сюда же входит близкая к программированию и математике логика, то он не будет способен строить системы и решать концептуальные вопросы этих систем, не говор уже о том, что, не зря ли он учился...
Автор писал о профессионализме, оспаривая, в том числе, присутствие философии в программе обучения. Я думаю, что самая минимальная подготовка по курсу философии вполне себе входит в список компетенций «профессионала».
К сожалению, вузы в большинстве своём выпускают людей, которые неспособны обучаться самостоятельно, и в этом самая главная проблема. В лучшем случае они умеют работать со стандартизированными протоколами.
Я преподавал программирование подросткам, поэтому мои оценки в отношении выпускников ВУЗов могут быть субъективными.
Спасибо, я догадывался, но поспешил с терминологическими определениями.