Не могу не одобрять изучение раста, но все же не до конца понятно какую проблему это решает. Проперти в Java/C# решают проблему того, что кто-нибудь может что-нибудь не то случайно намутировать, потоу что там мутабельность — свойство типа, а не переменной. В расте соответственно такой проблемы нет.
Второй вопрос, который решают не сами проперти, а их использование в интерфейсах — гарантия, что некое поле существует. В расте это иногда нужно, но на практике достаточно обычно сделать трейт вида
pub trait EntityId {
fn id() -> Id;
}
Ну и утилити макрос чтоб в 1 строчку реализовывать его:
Попытка вернуть обработку обратно в один поток показала, что общее время выполнения всех операций становится значительно меньше, но превращается в "один гигантский фриз".
Достаточно было просто сократить количество обменов сообщений, не посылая их по одному а пачками скажем по 100 или 1000. Менять дизайн системы практически не нужно, просто вставить батчинг в 1 месте и цикл в другом, общее количество изменений — десяток строк.
Насколько мне известно единственный нормальный файловый асинк есть только в винде. В линксе вроде худо-бедно запилили io_uring, но его поддержка ещё все же хромает во многих языках и платформах.
Как и любая аналогия это не одно и то же, потому что что угодно отличается от чего угодно другого, кроме себя. Однако показывает идею — что у нас есть математически непротиворечивые выводы, которые проверить можно только практикой.
Если мы ищем корень уравнения x^2=4 то у нас есть два ответа +-2. При этом один корень описывает количество яблок которые лежат на столе у васи, а другой — не очень. Математики тут плохо проделали свою работу выходит? Разнве результаты ведь получаются.
То есть тестировщикам тяжело проверять одно и то же по сто раз, и теперь из жалости, программист должен проверять одно и то же сто раз?
Программистам ничего проверять не надо, проверяет компьютер сам себя.
Вообще, в моём представлении, тестировщики ничего и не проверяют по сто раз, а пишут e2e тесты, которые и проверяют, выполняет ли программа бизнес-задачи.
Предлагаю решить задачу выше: как написать е2е тесты что емейлы приходят, или наоборот, что они НЕ приходят при выполнении определенного условия, а в обычное время должны прийти. В случае с юнит тестом это две очевидные строчки и 0.02мс на выполнение теста, а вот как быть в случае с е2е страшно представить.
Надо понимать, что тесты лни для разработчика, как типы и все остальное. Что некоторые считают "шумом", который "мешает творить".
Алсо
Вообще, в моём представлении, тестировщики ничего и не проверяют по сто раз, а пишут e2e тесты
У меня был не оди ни не два проекта где тестировщики не пиали тесты вообще, потому чо не умели. Они знали про ящики, могли нажимать кнопки, а что такое питон — что-то в зоопарке. Куа умеющий в тесты это сразу х1.5 к зп, и да, я считаю что оно того обычно стоит, но во-первых не все можно автоматизировать легко, во-вторыху бизнеса иногда свои представления.
А была другая работа где тестировщиков не было как класса, и весь-весь продукт покрывался исключительно юнит-тестами (с редкими вкраплениями интеграционных). И ничего, отлично продавался, имея данон, панасоник, бургеркинг и ещё несколько сотен подобных наименований в виде клиентов. Причем работал весьма неплохо, несмотря на Ci/CD и автодеплой по результатам прохождения тестов.
Во-первых то что выше написали. Во-вторых обратная связь вместо "нажал кнопку и получил ответ от теста через 5 секунд" начинает занимать дни или даже недели. Не говоря про то, что тестировщики тоже люди и проверять одно и то же по 100 раз им тяжело. У нас был проект с текучкой тестировщиков, не супер хорошая штука — тестировщик как и любой другой специалист сильно экономит время когда знает проект и не задает очевидных для тех кто уже немного пожил в проекте вопросов.
Ну под ошибкой я понаю ошибку от компилятора. Эксепшон в рантайме это не ошибка а ерундень. Такой уровень безопансости дает практически любой язык, от сишки до жс, но этот уровень околонулевой. Все что не ловится статическими чекерами — потенциальная дыра.
Так я это написал не в пику, а в поддержку) Я знаю, что мы в этом плане согласны.
Тесты же дают нам какие-никакие гарантии, причем эти гарантии чисто на нашей стороне, реальное приложение не тормозит от них. Да, не серебряная пуля, но жизнь упрощают знатно.
Вот вот. Я их пишу не потому что я религиозно следую заветам дядь из книжек, а потому что куда проще и быстрее в ограниенном пространстве без зависимостей проверить что работает что-то ожидаемым образом. Если каждый компонент написан правильно, то сломаться может только неправильным комбинированием. А если не проверить это то понять что пошло не так становится экспоненциально сложно. Просто позиция что тесты это долго напоминает мне боянистую картинку про колесо:
Да дело не в больших долгоживущих проектах. Вот например я привел выше пример, который упорно товарищ автор игнорирует. Про систему рассылки. Мне в 100000 раз быстрее написать тест который просто проверяет expect(getDecision(getTestState(Day.Saturday), testUser)).to.be.eq(Decision.DoNotSendEmail). Как без юнит-теста это проверять? Поднимать ради этого тестовую почту, заводить тестовых юзеров? Алсо как удостовериться что письмо не отправилось потому чт омы его не отправили, а не потому что оно где-нибудь в спам фильтрах застряло? Классная альтернатива по сравнению с yarn test который прогонит все сценарии за пару секунд. Может быть вообще не проверять? Вопросы, вопросы...
Ну работайте в эксель-97, кто ж вам запрещает. Это ж какая экономия на апгрейдах.
Мультик про корову очень хороший, но не к месту
Второй видос низкопробное кловунярство. Над растом можно посмеяться куда умнее скажем
Но чел несет не очень смешную и уместную пургу.
Первое апреля в этом году настало раньше положенного
Не могу не одобрять изучение раста, но все же не до конца понятно какую проблему это решает. Проперти в Java/C# решают проблему того, что кто-нибудь может что-нибудь не то случайно намутировать, потоу что там мутабельность — свойство типа, а не переменной. В расте соответственно такой проблемы нет.
Второй вопрос, который решают не сами проперти, а их использование в интерфейсах — гарантия, что некое поле существует. В расте это иногда нужно, но на практике достаточно обычно сделать трейт вида
Ну и утилити макрос чтоб в 1 строчку реализовывать его:
Хм, а я думаю чего это меня стойкое ощущение что я это уже видел...
Где в название что-то про ускорение си?
Вероятность получить полезный ответ от товарища Карловского в точности равна нулю, это знание в будущем может экономить неплохо время.
Надеюсь у вас дом обнесут трехметровым забором, тогда даже бабушки-одуванчики станут профессионалами в прыжках с шестом.
А, это не генерик коллекция. Я вообще забыл об их существовании, даже не посмотрел дальше. Окей, принимается.
Я не туда смотрю?..
Достаточно было просто сократить количество обменов сообщений, не посылая их по одному а пачками скажем по 100 или 1000. Менять дизайн системы практически не нужно, просто вставить батчинг в 1 месте и цикл в другом, общее количество изменений — десяток строк.
Насколько мне известно единственный нормальный файловый асинк есть только в винде. В линксе вроде худо-бедно запилили io_uring, но его поддержка ещё все же хромает во многих языках и платформах.
Как и любая аналогия это не одно и то же, потому что что угодно отличается от чего угодно другого, кроме себя. Однако показывает идею — что у нас есть математически непротиворечивые выводы, которые проверить можно только практикой.
Если мы ищем корень уравнения x^2=4 то у нас есть два ответа +-2. При этом один корень описывает количество яблок которые лежат на столе у васи, а другой — не очень. Математики тут плохо проделали свою работу выходит? Разнве результаты ведь получаются.
Программистам ничего проверять не надо, проверяет компьютер сам себя.
Предлагаю решить задачу выше: как написать е2е тесты что емейлы приходят, или наоборот, что они НЕ приходят при выполнении определенного условия, а в обычное время должны прийти. В случае с юнит тестом это две очевидные строчки и 0.02мс на выполнение теста, а вот как быть в случае с е2е страшно представить.
Надо понимать, что тесты лни для разработчика, как типы и все остальное. Что некоторые считают "шумом", который "мешает творить".
Алсо
У меня был не оди ни не два проекта где тестировщики не пиали тесты вообще, потому чо не умели. Они знали про ящики, могли нажимать кнопки, а что такое питон — что-то в зоопарке. Куа умеющий в тесты это сразу х1.5 к зп, и да, я считаю что оно того обычно стоит, но во-первых не все можно автоматизировать легко, во-вторыху бизнеса иногда свои представления.
А была другая работа где тестировщиков не было как класса, и весь-весь продукт покрывался исключительно юнит-тестами (с редкими вкраплениями интеграционных). И ничего, отлично продавался, имея данон, панасоник, бургеркинг и ещё несколько сотен подобных наименований в виде клиентов. Причем работал весьма неплохо, несмотря на Ci/CD и автодеплой по результатам прохождения тестов.
Во-первых то что выше написали. Во-вторых обратная связь вместо "нажал кнопку и получил ответ от теста через 5 секунд" начинает занимать дни или даже недели. Не говоря про то, что тестировщики тоже люди и проверять одно и то же по 100 раз им тяжело. У нас был проект с текучкой тестировщиков, не супер хорошая штука — тестировщик как и любой другой специалист сильно экономит время когда знает проект и не задает очевидных для тех кто уже немного пожил в проекте вопросов.
Ну под ошибкой я понаю ошибку от компилятора. Эксепшон в рантайме это не ошибка а ерундень. Такой уровень безопансости дает практически любой язык, от сишки до жс, но этот уровень околонулевой. Все что не ловится статическими чекерами — потенциальная дыра.
Так я это написал не в пику, а в поддержку) Я знаю, что мы в этом плане согласны.
Вот вот. Я их пишу не потому что я религиозно следую заветам дядь из книжек, а потому что куда проще и быстрее в ограниенном пространстве без зависимостей проверить что работает что-то ожидаемым образом. Если каждый компонент написан правильно, то сломаться может только неправильным комбинированием. А если не проверить это то понять что пошло не так становится экспоненциально сложно. Просто позиция что тесты это долго напоминает мне боянистую картинку про колесо:
Да дело не в больших долгоживущих проектах. Вот например я привел выше пример, который упорно товарищ автор игнорирует. Про систему рассылки. Мне в 100000 раз быстрее написать тест который просто проверяет
expect(getDecision(getTestState(Day.Saturday), testUser)).to.be.eq(Decision.DoNotSendEmail). Как без юнит-теста это проверять? Поднимать ради этого тестовую почту, заводить тестовых юзеров? Алсо как удостовериться что письмо не отправилось потому чт омы его не отправили, а не потому что оно где-нибудь в спам фильтрах застряло? Классная альтернатива по сравнению сyarn testкоторый прогонит все сценарии за пару секунд. Может быть вообще не проверять? Вопросы, вопросы...