Снижение производительности - вероятно, во всех других случаях обработки Result мы никогда не выполняем проверку на Ok или Err (то есть это замечание - явная ложь).
Непредсказуемое поведение - не могу придумать ни одного примера.
Отчего это читабельность кода снизится? Я вот совсем не вижу этого снижения.
Паника - не трудноотслеживаемая ошибка ни разу. И ошибки она никак не маскирует. В общем вся статья - ошибка от начала и до конца. Единственно, желательно вместо unwrap использовать expect - тогда сообщение паники можно сделать более содержательным.
Только хороший тимлид знает что и как можно выжать из комманды. Как пилот формулы один. А попытка посадить на место пилота бригаду из двигателя и карбюратора под диктатом спонсора комманды - ну может и доедут до финиша...
Все же по моему техлид != тимлид и руководство - это как раз то, от чего техлиды бегут, как черт от ладана :-) Хотя хорошая книга никогда не помешает...
Вот вы похоже Rust не знаете. Там unsafe не такой как C++ - то есть совсем. И дает кучу гарантий. А с синтаксисом. Просто он не сишный в своей основе - а парсить современные плюсы человеку вообще невозможно - одни темплейты вышибают напрочь на часы.
У вас цифры явно заниженные... 4 месяца разработки 1 нормальным спецом - уже 1.5 млн. Плюс налоги, плюс бас фактор. Думаю реальная цифра 15-20 млн где то. А за 2-3 - поделка на коленке, умирающая под нагрузкой.
Факт пр ORM известный - за использование упрощенной модели взаимодействия объект<-> реляционная БД (лень разработчика и экономия его времени - эфемерная кстати), придется платить клиенту. Чаще всего не только за железо, но и за разболтанные нервы и впустую потраченноле время на ожидение пользователя. Хотя чаще всего тут ДАЖЕ не нужно массовых вставок, достаточно одного-двух мерджей и индекированной вьюшки. Я лично уже несколько лет пользую Linq2Db - прекрасную возможность писать практически на Sql, но с проверками типов на этапе компиляции. К сожелению, библиотека строго под Csharp, аналогов этой библиотеки я не встречал в других языках и экосистемах.
3 продукта от майков и два коммерческих... Не густо. Говорит о востребованности и используемости системы. Нужно ли тратить силы на столь нишевый продукт? я бы даже немного уточнил - этот спектр задач не может решить один докер под виндовс (контейнеры под виндовс) в области хостинга?
Покупатель всегда прав. А работодатель это покупатель, он голосует рублем. И тут нельзя быть плохим продавцом. А вот почему он не купил товар - может пуговицы не перламутрувые, а может дорого, а может цвет не подошел ... Не всякий раз узнаешь...
Как раз конечный. Обычно человек немногое знает о том, что он не знает. :-) И вот тут я соглашусь - лучше бы написать, что "не имею релевантного опыта работы с версионными БД, только с блокировочниками" - сказать, что и впрям с Postgre на вы, но красиво
Про задачу: можете попробовать, как математику вам может быть интересно, посмотреть в сторону, например, асинхронной отправки в RabbitMq с таймаутом. Там простая, но забавная задачка на очереди в памяти с произвольным доступом и автоматическим эжектом. Особенно веселые в многопотоке. Сами по себе менеджеры очередей не очень сложные (хотя топологические возможности кролика позволяют, например, создать на нем распределенный планировщик заданий - но это уже некоторое больше академическое извращение). Обычно потребность в них возникает в микросервисных системах, я даже сказал бы, что они без месседж брокера в принципе не проектируются почти. а там из за консистентности в конечном итоге сразу встает в полный рост задача гарантированной доставки сообщения до очереди. Вот и попробуйте написать два простых микросервиса - один хранит например в постгрессе расписание человека и им управляет (занимает и освобождает время по запросу), а другой использует, но должен знать, что вот на это событие удалось или не удалось распределить на человека (у него своя база, где он это отмечает).
Собственно, я и сижу в теплом кресле с кошкой на коленях и ни разу не выгорел :-) Однако рос, как специалист (не карьерно, это само прикладывалось) в течении всех 30 с лишним лет профессионального опыта :-) А то придут молодые и упертые и тут ты уже правда не нужен.
Расставлю сразу точки над - мне за 50 и я программист, а не рекрутер. Но вот вы огорчаетесь, что вам не сообщили об ограничениях на возраст. Мне кажется, что по другую сторону экрана был довольно молодой человек, который воспитан настолько хорошо, при этом конечно юридически не грамотен, что просто попытылся реально ,не обидив Вас, отказать. Потому что я сомневаюсь, что Вы менее эффективны, чем специалист на 25 лет моложе вас, но вот времени для развития у него все же больше. И когда говорят о возрастном пороге, все же релевантно оценивать не возраст, а профессиональный опыт. А здесь по Вашему описанию себя - Вы джун. А нас, стариков, если видит рядом с собой молодежь, то сеньорного и выше уровня. Потому как даже мне бы было просто неудобно учить человека в нашем возрасте простым вещам. Просто неудобно лекцию ему читать. И вот уж тут, простите, ничего не сделаешь не статистикой, ничем другим.
Снижение производительности - вероятно, во всех других случаях обработки Result мы никогда не выполняем проверку на Ok или Err (то есть это замечание - явная ложь).
Непредсказуемое поведение - не могу придумать ни одного примера.
Отчего это читабельность кода снизится? Я вот совсем не вижу этого снижения.
Паника - не трудноотслеживаемая ошибка ни разу. И ошибки она никак не маскирует. В общем вся статья - ошибка от начала и до конца. Единственно, желательно вместо unwrap использовать expect - тогда сообщение паники можно сделать более содержательным.
Только хороший тимлид знает что и как можно выжать из комманды. Как пилот формулы один. А попытка посадить на место пилота бригаду из двигателя и карбюратора под диктатом спонсора комманды - ну может и доедут до финиша...
Все же по моему техлид != тимлид и руководство - это как раз то, от чего техлиды бегут, как черт от ладана :-) Хотя хорошая книга никогда не помешает...
Вот вы похоже Rust не знаете. Там unsafe не такой как C++ - то есть совсем. И дает кучу гарантий. А с синтаксисом. Просто он не сишный в своей основе - а парсить современные плюсы человеку вообще невозможно - одни темплейты вышибают напрочь на часы.
Я готов согласиться, когда речь идет о плоских C. Но ОДНА база данных из всех (остальные не на плюсах) кажется мне вполне себе показателем.
SPA и API
Забавно... Шаблонизатор в современном вебе... Лет 5 уже не сталкивался.
Странно, но не похоже на работу техлида - все же техлид - это о технологиях, а не о скрамах
У вас цифры явно заниженные... 4 месяца разработки 1 нормальным спецом - уже 1.5 млн. Плюс налоги, плюс бас фактор. Думаю реальная цифра 15-20 млн где то. А за 2-3 - поделка на коленке, умирающая под нагрузкой.
В такой записи не вижу принципиальной разницы
Продемонстрируйте простыню golang для этого же :-).
Факт пр ORM известный - за использование упрощенной модели взаимодействия объект<-> реляционная БД (лень разработчика и экономия его времени - эфемерная кстати), придется платить клиенту. Чаще всего не только за железо, но и за разболтанные нервы и впустую потраченноле время на ожидение пользователя. Хотя чаще всего тут ДАЖЕ не нужно массовых вставок, достаточно одного-двух мерджей и индекированной вьюшки. Я лично уже несколько лет пользую Linq2Db - прекрасную возможность писать практически на Sql, но с проверками типов на этапе компиляции. К сожелению, библиотека строго под Csharp, аналогов этой библиотеки я не встречал в других языках и экосистемах.
3 продукта от майков и два коммерческих... Не густо. Говорит о востребованности и используемости системы. Нужно ли тратить силы на столь нишевый продукт? я бы даже немного уточнил - этот спектр задач не может решить один докер под виндовс (контейнеры под виндовс) в области хостинга?
Покупатель всегда прав. А работодатель это покупатель, он голосует рублем. И тут нельзя быть плохим продавцом. А вот почему он не купил товар - может пуговицы не перламутрувые, а может дорого, а может цвет не подошел ... Не всякий раз узнаешь...
Молодые болеют реже, но болеют. А опытные... 8 месяцев химио-лучевой терапии без отрыва от производства.. Ну попробуйте :-)
Я - LINQ - красивый, умный и ленивый. Так что всех, но по разному :-)
Как раз конечный. Обычно человек немногое знает о том, что он не знает. :-) И вот тут я соглашусь - лучше бы написать, что "не имею релевантного опыта работы с версионными БД, только с блокировочниками" - сказать, что и впрям с Postgre на вы, но красиво
Про задачу: можете попробовать, как математику вам может быть интересно, посмотреть в сторону, например, асинхронной отправки в RabbitMq с таймаутом. Там простая, но забавная задачка на очереди в памяти с произвольным доступом и автоматическим эжектом. Особенно веселые в многопотоке. Сами по себе менеджеры очередей не очень сложные (хотя топологические возможности кролика позволяют, например, создать на нем распределенный планировщик заданий - но это уже некоторое больше академическое извращение). Обычно потребность в них возникает в микросервисных системах, я даже сказал бы, что они без месседж брокера в принципе не проектируются почти. а там из за консистентности в конечном итоге сразу встает в полный рост задача гарантированной доставки сообщения до очереди. Вот и попробуйте написать два простых микросервиса - один хранит например в постгрессе расписание человека и им управляет (занимает и освобождает время по запросу), а другой использует, но должен знать, что вот на это событие удалось или не удалось распределить на человека (у него своя база, где он это отмечает).
Собственно, я и сижу в теплом кресле с кошкой на коленях и ни разу не выгорел :-) Однако рос, как специалист (не карьерно, это само прикладывалось) в течении всех 30 с лишним лет профессионального опыта :-) А то придут молодые и упертые и тут ты уже правда не нужен.
Расставлю сразу точки над - мне за 50 и я программист, а не рекрутер. Но вот вы огорчаетесь, что вам не сообщили об ограничениях на возраст. Мне кажется, что по другую сторону экрана был довольно молодой человек, который воспитан настолько хорошо, при этом конечно юридически не грамотен, что просто попытылся реально ,не обидив Вас, отказать. Потому что я сомневаюсь, что Вы менее эффективны, чем специалист на 25 лет моложе вас, но вот времени для развития у него все же больше. И когда говорят о возрастном пороге, все же релевантно оценивать не возраст, а профессиональный опыт. А здесь по Вашему описанию себя - Вы джун. А нас, стариков, если видит рядом с собой молодежь, то сеньорного и выше уровня. Потому как даже мне бы было просто неудобно учить человека в нашем возрасте простым вещам. Просто неудобно лекцию ему читать. И вот уж тут, простите, ничего не сделаешь не статистикой, ничем другим.