Как стать автором
Обновить
4
1.1
Григорий Бочаров @FlyingDutchman2

Senior Developer

Отправить сообщение

В одной компании на собеседовании расспрашивали про отношение к одной религии (на полном серьезе).

Такое не только у вас бывает. У нас в Голландии была компания Baan Software (очень известная в 1990е годы своей ERP-системой). Она была основана ортодоксальными протестантами. И на собеседовании там кандидатам тоже задавали вопросы про религию и недостаточно религиозных отсеивали.

"Нидерландский язык" - официальное название, "голландский" - неофициальное название нидерландского.

Сторонники: умение/владение языком программирования позволяет делать более качественные ТЗ

Голосую обеими руками за. Кто-то сказал (уже не помню кто): "Аналитик - это непрограммирующий программист".

Недавно я поработал на проекте, в котором использовались 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(), но все равно получается читабельнее.

Лично мне читать это сложно:

    persons.Should().ContainSingle(x => x.name == "Егор").Which.age.Should().BeGreaterThan(9);

Я вообще сторонник писать проверку каждого условия в отдельной строке:

    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 в виде подставки для мыши, в которую встроен небольшой диск, который вращается моторчиком. Мышь ставится на диск сверху.

Я переписал скрипт, сделав код немного более читабельным:

import pyautogui, random, time

screen = pyautogui.size()
sleep_interval_sec = 10
move_duration_sec = 0.5

print(f'''Random mouse moving started
Screen width = {screen.width}, screen height = {screen.height}
Sleep interval = {sleep_interval_sec} sec.
Move duration = {move_duration_sec} sec.''')

step = 0
while True:
    print(f'Step: {step}')

    new_X = random.randrange(0, screen.width)
    new_Y = random.randrange(0, screen.height)
    pyautogui.moveTo(new_X, new_Y, move_duration_sec)

    time.sleep(sleep_interval_sec)
    step += 1

Мне 55 лет. Согласен с большинством пунктов.

В итоге мне отказали, сказав, что мой английский не дотягивает до их требований, и слишком много времени занято другими проектами.

Голландцы часто не заморачиваются тем, чтобы придумать правдоподобную причину для отказа. Например, в 2020 году меня было собеседование в одну голландскую компанию. После собеседования мне прислали отказ с мотивацией "плохой голландский". Это при том. что я живу здесь 25 лет, по-голландски говорю свободно (хотя и с акцентом). Во время разговора у меня не было ощущения, что мой собеседник чего-то не понимал.

Затем я собрал генератор онлайнового микромагазина, продающего на повторе один и тот же товар; можно сказать, это крошечный Shopify.

Кстати, вполне работающая идея. В Голландии несколько лет назад существовал веб-магазин 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

"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.

Я уж лучше в обычной компании поработаю.

J.E. Sammet помогал разрабатывать COBOL и одним из первых задался вопросом

Только не "помогал", а "помогала". Jean Sammet - женщина.

Да, именно так и появился Facebook :-)

Как мне кажется, слепая печать, git и навыки хоть какого-то программирования входят в базовый перечень для любого причастного к компьютерам, вместе с умением читать и писать.

Git - это одна из десятков используемых систем контроля версий, поэтому кажется странным приравнивать знание git к умению читать и писать. К примеру, я работал с различными системами контроля версий начиная с 1999 года, а с git познакомился только через 20 лет, в 2019 году.

Мои впечатления после прочтения нескольких десятков статей Спольски несколько лет назад:

  1. Процентов 10 статей, а то и меньше, содержат полезную информацию, остальное графоманство. Мне непонятно, почему он так популярен.

  2. Его знания программирования довольно поверхностные.

  3. Похоже, что он как предприниматель и менеджер он довольно неплох.

Информация

В рейтинге
1 348-й
Откуда
Arnhem, Gelderland, Нидерланды
Зарегистрирован
Активность