Попахивает велосипедом... Автор спрашивал мнение пользователей других языков:
оператор pop реализован в Rust макросом ?. Для его использования достаточно, чтобы выражение возвращало Result<T, E> или Option<T>. Конечно нужно контролировать тип ошибки.
мечта о произвольном pattern matching реализована, например, в FSharp, как Active Patterns - любая функция, принимающая на вход сопоставляемое выражение и возвращающая Option<T> - матчер сопоставляемого выражения с T.
Pattern Dependency Injection реализуется в ФП с поимощью монады Reader. Собственно монада и предполагает некоторый контекст над типом, так что и мысль о таскаемом за собой контексте что то очень напоминает монаду State.
Снижение производительности - вероятно, во всех других случаях обработки Result мы никогда не выполняем проверку на Ok или Err (то есть это замечание - явная ложь).
Непредсказуемое поведение - не могу придумать ни одного примера.
Отчего это читабельность кода снизится? Я вот совсем не вижу этого снижения.
Паника - не трудноотслеживаемая ошибка ни разу. И ошибки она никак не маскирует. В общем вся статья - ошибка от начала и до конца. Единственно, желательно вместо unwrap использовать expect - тогда сообщение паники можно сделать более содержательным.
Только хороший тимлид знает что и как можно выжать из комманды. Как пилот формулы один. А попытка посадить на место пилота бригаду из двигателя и карбюратора под диктатом спонсора комманды - ну может и доедут до финиша...
Все же по моему техлид != тимлид и руководство - это как раз то, от чего техлиды бегут, как черт от ладана :-) Хотя хорошая книга никогда не помешает...
Вот вы похоже Rust не знаете. Там unsafe не такой как C++ - то есть совсем. И дает кучу гарантий. А с синтаксисом. Просто он не сишный в своей основе - а парсить современные плюсы человеку вообще невозможно - одни темплейты вышибают напрочь на часы.
У вас цифры явно заниженные... 4 месяца разработки 1 нормальным спецом - уже 1.5 млн. Плюс налоги, плюс бас фактор. Думаю реальная цифра 15-20 млн где то. А за 2-3 - поделка на коленке, умирающая под нагрузкой.
Факт пр ORM известный - за использование упрощенной модели взаимодействия объект<-> реляционная БД (лень разработчика и экономия его времени - эфемерная кстати), придется платить клиенту. Чаще всего не только за железо, но и за разболтанные нервы и впустую потраченноле время на ожидение пользователя. Хотя чаще всего тут ДАЖЕ не нужно массовых вставок, достаточно одного-двух мерджей и индекированной вьюшки. Я лично уже несколько лет пользую Linq2Db - прекрасную возможность писать практически на Sql, но с проверками типов на этапе компиляции. К сожелению, библиотека строго под Csharp, аналогов этой библиотеки я не встречал в других языках и экосистемах.
3 продукта от майков и два коммерческих... Не густо. Говорит о востребованности и используемости системы. Нужно ли тратить силы на столь нишевый продукт? я бы даже немного уточнил - этот спектр задач не может решить один докер под виндовс (контейнеры под виндовс) в области хостинга?
Покупатель всегда прав. А работодатель это покупатель, он голосует рублем. И тут нельзя быть плохим продавцом. А вот почему он не купил товар - может пуговицы не перламутрувые, а может дорого, а может цвет не подошел ... Не всякий раз узнаешь...
Как раз конечный. Обычно человек немногое знает о том, что он не знает. :-) И вот тут я соглашусь - лучше бы написать, что "не имею релевантного опыта работы с версионными БД, только с блокировочниками" - сказать, что и впрям с Postgre на вы, но красиво
Про задачу: можете попробовать, как математику вам может быть интересно, посмотреть в сторону, например, асинхронной отправки в RabbitMq с таймаутом. Там простая, но забавная задачка на очереди в памяти с произвольным доступом и автоматическим эжектом. Особенно веселые в многопотоке. Сами по себе менеджеры очередей не очень сложные (хотя топологические возможности кролика позволяют, например, создать на нем распределенный планировщик заданий - но это уже некоторое больше академическое извращение). Обычно потребность в них возникает в микросервисных системах, я даже сказал бы, что они без месседж брокера в принципе не проектируются почти. а там из за консистентности в конечном итоге сразу встает в полный рост задача гарантированной доставки сообщения до очереди. Вот и попробуйте написать два простых микросервиса - один хранит например в постгрессе расписание человека и им управляет (занимает и освобождает время по запросу), а другой использует, но должен знать, что вот на это событие удалось или не удалось распределить на человека (у него своя база, где он это отмечает).
Собственно, я и сижу в теплом кресле с кошкой на коленях и ни разу не выгорел :-) Однако рос, как специалист (не карьерно, это само прикладывалось) в течении всех 30 с лишним лет профессионального опыта :-) А то придут молодые и упертые и тут ты уже правда не нужен.
Попахивает велосипедом... Автор спрашивал мнение пользователей других языков:
оператор pop реализован в Rust макросом ?. Для его использования достаточно, чтобы выражение возвращало Result<T, E> или Option<T>. Конечно нужно контролировать тип ошибки.
мечта о произвольном pattern matching реализована, например, в FSharp, как Active Patterns - любая функция, принимающая на вход сопоставляемое выражение и возвращающая Option<T> - матчер сопоставляемого выражения с T.
Pattern Dependency Injection реализуется в ФП с поимощью монады Reader. Собственно монада и предполагает некоторый контекст над типом, так что и мысль о таскаемом за собой контексте что то очень напоминает монаду State.
Снижение производительности - вероятно, во всех других случаях обработки 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 с лишним лет профессионального опыта :-) А то придут молодые и упертые и тут ты уже правда не нужен.