Недавно я поработал на проекте, в котором использовались Fluent Assertions.
Ничего не могу сказать по поводу сообщений об ошибках. Меня в принципе устраивает, как это реализовано в стандартных фреймворках типа MSTest.
Но вот что мне не понравилось в Fluent Assertions, так это ухудшение читабельности и легкости написания кода из-за безудержного использования Fluent Interface.
Вот это хоть и выглядит короче
10.May(2020).At(21, 20, 30)
но менее понятно, чем чуть более длинное
new DateTime(2020, 5, 10, 21, 20, 30)
Здесь вообще очень длинно
age.Should().BeGreaterThan(9)
по сравнению с
age > 9
Конечно, эти два выражения не эквивалентны по функциональности и второе нужно еще обернуть в Assert.IsTrue(), но все равно получается читабельнее.
Я вообще сторонник писать проверку каждого условия в отдельной строке:
person = persons[1];
Assert.AreEqual(person.name, "Егор");
Assert.IsTrue(person.age > 9);
(это не совсем то, что в оригинальном коде, но моя мысль понятна)
С написанием кода с использованием Fluent Assertions у меня тоже проблемы:
Надо выучить десятки (а может, их там сотни?) всех этих методов типа BeGreaterThan.
Надо помнить, где ставить точку и где не ставить.
То же самое касается круглых скобок.
В качестве преимущества использования Fluent Assertions приводится возможность "читать код как книгу на английском языке". Но зачем вообще это нужно? (Тут вспоминается Эдсгер Дейкстра с его высказыванием "Проекты, предлагающие программирование на естественном языке, гибельны по своей сути").
Эти эксперименты с Fluent interface напоминают язык COBOL. Например, в C# мы пишем
a = b;
а в языке COBOL присваивание записывается так (этот язык тоже создавался для того, чтобы пользователи-непрограммисты могли создавать программы на человеческом языке):
Move b to a.
Как видим, это правильное предложение на английском, и даже точка в конце. Но потом языки программирования пошли по другому пути, и код стало можно писать короче и выразительнее.
В C# мы тоже можем создать библиотеку при помощи Fluent interface, чтобы писать в стиле COBOL, что-то в этом роде:
Move().b.To().a;
но зачем это нужно делать в 2022 году? А Fluent Assertions выглядит так, как будто нам в XXI веке пытаются подсунуть стиль программирования из 1960 года.
Вся история развития искусственно созданных языков (не только языков программирования, но я других, например, языка электрических схем или географических схем) говорит о другом - с течением времени язык становится лаконичнее и выразительнее.
В статье среди металлов не упоминается тантал. А я помню, как лет сорок назад отец показывал мне какое-то специальное реле, в котором были контакты из тантала (красивого сиреневого цвета). Тантал был очень дорог, и когда реле выбрасывали, то контакты в обязательном порядке выпаивались и возвращались обратно на завод, где их производили.
С интересом прочитал статью. В ней много умных вещей. Например, я впервые в жизни увидел выражение Code Churn (хотя работаю программистом уже 30 лет). Наверное, все это - хорошая тема для кандидатской диссертации на тему управления проектами. Но работать на проекте, в котором используются такие вот KPI, очень не хотелось бы.
Я купил себе для этих целей mouse jiggler в виде подставки для мыши, в которую встроен небольшой диск, который вращается моторчиком. Мышь ставится на диск сверху.
В итоге мне отказали, сказав, что мой английский не дотягивает до их требований, и слишком много времени занято другими проектами.
Голландцы часто не заморачиваются тем, чтобы придумать правдоподобную причину для отказа. Например, в 2020 году меня было собеседование в одну голландскую компанию. После собеседования мне прислали отказ с мотивацией "плохой голландский". Это при том. что я живу здесь 25 лет, по-голландски говорю свободно (хотя и с акцентом). Во время разговора у меня не было ощущения, что мой собеседник чего-то не понимал.
Затем я собрал генератор онлайнового микромагазина, продающего на повторе один и тот же товар; можно сказать, это крошечный Shopify.
Кстати, вполне работающая идея. В Голландии несколько лет назад существовал веб-магазин One Day Fly, в котором в течение одного дня (24 часа) продавался один товар. Правда, с течением времени этот магазин эволюционировал в магазин, в котором продается много товаров (каждый в течение одного дня). https://www.koopjedeal.nl/
У юристов была/есть проблема, что пункты в различных договорах одинаковые и если надо внести изменения в одном таком пункте, то надо пересмотреть абсолютно все договора, где он участвует.
Решение, которое сразу приходит в голову - использовать TeX (а точнее макропакет LaTeX) для написания договоров и оформлять пункты договоров отдельными макросами. После чего очень легко поменять какой-нибудь пункт договора.
Но, к сожалению, TeX не особо популярен, особенно среди юристов...
"When I interview people I tell them, 'You can work long, hard, or smart, but at Amazon.com you can't choose two out of three," Bezos wrote in the 1997 letter.
Как мне кажется, слепая печать, git и навыки хоть какого-то программирования входят в базовый перечень для любого причастного к компьютерам, вместе с умением читать и писать.
Git - это одна из десятков используемых систем контроля версий, поэтому кажется странным приравнивать знание git к умению читать и писать. К примеру, я работал с различными системами контроля версий начиная с 1999 года, а с git познакомился только через 20 лет, в 2019 году.
"Нидерландский язык" - официальное название, "голландский" - неофициальное название нидерландского.
И это тоже
Голосую обеими руками за. Кто-то сказал (уже не помню кто): "Аналитик - это непрограммирующий программист".
Недавно я поработал на проекте, в котором использовались Fluent Assertions.
Ничего не могу сказать по поводу сообщений об ошибках. Меня в принципе устраивает, как это реализовано в стандартных фреймворках типа MSTest.
Но вот что мне не понравилось в Fluent Assertions, так это ухудшение читабельности и легкости написания кода из-за безудержного использования Fluent Interface.
Вот это хоть и выглядит короче
но менее понятно, чем чуть более длинное
Здесь вообще очень длинно
по сравнению с
Конечно, эти два выражения не эквивалентны по функциональности и второе нужно еще обернуть в Assert.IsTrue(), но все равно получается читабельнее.
Лично мне читать это сложно:
Я вообще сторонник писать проверку каждого условия в отдельной строке:
(это не совсем то, что в оригинальном коде, но моя мысль понятна)
С написанием кода с использованием Fluent Assertions у меня тоже проблемы:
Надо выучить десятки (а может, их там сотни?) всех этих методов типа BeGreaterThan.
Надо помнить, где ставить точку и где не ставить.
То же самое касается круглых скобок.
В качестве преимущества использования Fluent Assertions приводится возможность "читать код как книгу на английском языке". Но зачем вообще это нужно? (Тут вспоминается Эдсгер Дейкстра с его высказыванием "Проекты, предлагающие программирование на естественном языке, гибельны по своей сути").
Эти эксперименты с Fluent interface напоминают язык COBOL. Например, в C# мы пишем
а в языке COBOL присваивание записывается так (этот язык тоже создавался для того, чтобы пользователи-непрограммисты могли создавать программы на человеческом языке):
Как видим, это правильное предложение на английском, и даже точка в конце. Но потом языки программирования пошли по другому пути, и код стало можно писать короче и выразительнее.
В C# мы тоже можем создать библиотеку при помощи Fluent
interface, чтобы писать в стиле COBOL, что-то в этом роде:
но зачем это нужно делать в 2022 году? А Fluent Assertions выглядит так, как будто нам в XXI веке пытаются подсунуть стиль программирования из 1960 года.
Вся история развития искусственно созданных языков (не только языков программирования, но я других, например, языка электрических схем или географических схем) говорит о другом - с течением времени язык становится лаконичнее и выразительнее.
В статье среди металлов не упоминается тантал. А я помню, как лет сорок назад отец показывал мне какое-то специальное реле, в котором были контакты из тантала (красивого сиреневого цвета). Тантал был очень дорог, и когда реле выбрасывали, то контакты в обязательном порядке выпаивались и возвращались обратно на завод, где их производили.
С интересом прочитал статью. В ней много умных вещей. Например, я впервые в жизни увидел выражение Code Churn (хотя работаю программистом уже 30 лет). Наверное, все это - хорошая тема для кандидатской диссертации на тему управления проектами. Но работать на проекте, в котором используются такие вот KPI, очень не хотелось бы.
Наверное, у меня несовременная мышь (хотя и куплена несколько лет назад).
Я купил себе для этих целей mouse jiggler в виде подставки для мыши, в которую встроен небольшой диск, который вращается моторчиком. Мышь ставится на диск сверху.
Я переписал скрипт, сделав код немного более читабельным:
Мне 55 лет. Согласен с большинством пунктов.
Голландцы часто не заморачиваются тем, чтобы придумать правдоподобную причину для отказа. Например, в 2020 году меня было собеседование в одну голландскую компанию. После собеседования мне прислали отказ с мотивацией "плохой голландский". Это при том. что я живу здесь 25 лет, по-голландски говорю свободно (хотя и с акцентом). Во время разговора у меня не было ощущения, что мой собеседник чего-то не понимал.
Кстати, вполне работающая идея. В Голландии несколько лет назад существовал веб-магазин One Day Fly, в котором в течение одного дня (24 часа) продавался один товар. Правда, с течением времени этот магазин эволюционировал в магазин, в котором продается много товаров (каждый в течение одного дня). https://www.koopjedeal.nl/
А вот еще: решение головоломки Sudoku одним SQL-запросом: https://technology.amis.nl/it/solving-a-sudoku-with-1-sql-statement-the-model-clause/
Решение, которое сразу приходит в голову - использовать TeX (а точнее макропакет LaTeX) для написания договоров и оформлять пункты договоров отдельными макросами. После чего очень легко поменять какой-нибудь пункт договора.
Но, к сожалению, TeX не особо популярен, особенно среди юристов...
Прочитал про Безоса:
https://www.businessinsider.in/jeff-bezos-once-said-that-in-job-interviews-he-told-candidates-there-are-3-ways-to-work-and-at-amazon-you-have-to-do-all-3/articleshow/65343632.cms
Я уж лучше в обычной компании поработаю.
Только не "помогал", а "помогала". Jean Sammet - женщина.
Да, именно так и появился Facebook :-)
Git - это одна из десятков используемых систем контроля версий, поэтому кажется странным приравнивать знание git к умению читать и писать. К примеру, я работал с различными системами контроля версий начиная с 1999 года, а с git познакомился только через 20 лет, в 2019 году.
Мои впечатления после прочтения нескольких десятков статей Спольски несколько лет назад:
Процентов 10 статей, а то и меньше, содержат полезную информацию, остальное графоманство. Мне непонятно, почему он так популярен.
Его знания программирования довольно поверхностные.
Похоже, что он как предприниматель и менеджер он довольно неплох.
У него тоже спрашивали, как развернуть двоичное дерево?