Я услышал в одном подкасте (кажется, здесь), что затраты работодателя в России для увольнения работника по сокращению штатов составляют примерно 3 месячные зарплаты этого работника (если он работает по ТК). То есть при увольнении по соглашению сторон следует договариваться о компенсации не ниже этой суммы.
Кстати, у нас в Голландии при увольнении по сокращении штатов работнику выплачивается компенсация в размере примерно месячной зарплаты за каждый проработанный год (во всяком случае, раньше так было).
Поэтому, например, если человек проработал 20 лет на одном месте, то его очень трудно сократить.
На Западе указание такого в резюме — это действительно моветон и никогда-никогда.
It depends. У нас в Голландии фото в резюме не добавляется, а в соседней Германии является обязательным.
Цитата из голландской книги, посвященной поиску работы:
Немецкие компании считают важным, чтобы вы присылали фотографию вместе с вашим резюме. Вы прикрепляете свою фотографию в правом верхнем углу письма. На обратной стороне фотографии вы пишете своё имя и фамилию. Фотография должна быть сделана недавно, и вы должны выглядеть на ней естественно. Потенциальный работодатель оценивает вашу фотографию на основе мимики, одежды, общей ухоженности, качества фотографии (потратили ли вы усилия, чтобы сделать хорошее фото?). Размер фотографии должен быть примерно четыре на пять сантиметров.
Хотя эта книга была издана в 2004 и информация может быть устаревшей. Но подозреваю, что нет, учитывая консерватизм немцев.
Еще одно решение на Python с использованием механизма Pattern Matching:
'''
FizzBuzz demonstration using pattern matching
'''
def fizz_buzz(n):
isDivBy3 = n%3 == 0
isDivBy5 = n%5 == 0
match isDivBy3, isDivBy5:
case True, True:
result = 'FizzBuzz'
case True, False:
result = 'Fizz'
case False, True:
result = 'Buzz'
case False, False:
result = str(n)
case _:
raise Exception(f'Error processing number {n}')
return result
max_number = 100
for n in range(1, max_number + 1):
print(fizz_buzz(n))
Но, в отличие от Pattern Matching в C#, здесь нет проверки на логическую полноту условий. То есть, если убрать какое-либо из условий case, то не будет выдано никакого сообщения об ошибке.
С PL/I они завязли - получилось слишком уж сложно.
Почему завязли?
PL/I использовался очень широко (да и сейчас используется).
Например, в авиакомпании KLM PL/I являлся основным языком (COBOL тоже использовался). Я там проработал полтора года в конце 1990-х. Думаю, и сейчас они его активно используют.
И другие большие голландские компании (банки и т.д.) активно использовали PL/I.
В PL/I так же можно использовать встроенный SQL (для работы с СУБД Db2). И он лишен такого недостатка COBOL, как ужасный синтаксис.
помню недавно была пара месяцев когда ковырялся в нутрях огромного монолита… и по итогам четырех двухнедельных спринтов сгенерил 3 (три!!) коммита, причем два из них из 2-3х строчек
Мне это напомнило, как в 1998 году я в течение 2-х недель без перерыва искал причины одного хитрого бага в системе планирования полетов авиакомпании KLM. Сидел за компьютером не вставая с утра до вечера.
И потом по итогам расследования написал 3 строчки кода, решив проблему.
P.S. Как вспомню, так вздрогну. На мейнфреймах не было отладчиков, и единственным способом отладки была расстановка операторов PRINT в коде программы. При этом вывод записывался в один из трех файлов (файл выбирался случайным образом). При этом параллельно в эти файлы писали еще десятки программ, так что найти результаты моей печати само по себе было проблемой.
Вероятность того, что опечатка приведет к невыполнению всех условий вообще ничтожна
Я бы так не сказал. Такое случается чаще, чем мы думаем.
Я уже после многих лет работы стал немного параноидальным и в этих случаях всегда бросаю исключение в последней ветке if. Точно так же я в операторе switch перечисляю все варианты и обязательно добавляю выброс исключения в ветке default.
В общем, как говаривал начальник Первого Отдела из института ИРЭ АН УССР, в котором я работал в советское время: "Лучше перебдеть, чем недобдеть".
Тут я подумал, что было бы неплохо, если бы компилятор сам проверял бы, что все условия написаны без ошибок (т.е. были бы исчерпывающе полными). Но с Python это точно не получится.
Может быть, это удастся сделать при помощи механизма Pattern Matching из последней версии C#? Я провел небольшое исследование, и получилось. Отпала необходимость в выбрасывании исключения, да и код стал выглядеть понятнее, чем написанный на Python:
const int MaxNumber = 100;
for (int i = 1; i <= MaxNumber; i++)
{
Console.WriteLine(FizzBuzz(i));
}
static string FizzBuzz(int n)
{
var isDivBy3 = n % 3 == 0;
var isDivBy5 = n % 5 == 0;
var result = (isDivBy3, isDivBy5) switch
{
(true, true) => "FizzBuzz",
(true, false) => "Fizz",
(false, true) => "Buzz",
(false, false) => n.ToString()
};
return result;
}
Если здесь убрать одно из выражений из switch (например, первое), то Visual Studio выдаст предупреждение: CS8509 The switch expression does not handle all possible values of its input type (it is not exhaustive). For example, the pattern '(true, true)' is not covered.
Это предупреждение можно превратить в ошибку, и тогда код просто не скомпилируется (чтобы это сделать, нужно зайти в свойства проекта C#, раздел Build -> Errors and Warnings, секция Treat specific warnings as errors и внести в поле текст "CS8509").
Я давно занимаюсь Enterprise-программированием и мне часто приходится иметь дело со сложными бизнес-правилами. Так что решить такую простую задачку, как FizzBuzz, для меня будет несложно.
Я хочу у вас спросить, как у специалиста по FizzBuzz: какое ваше мнение по поводу моего решения для FizzBuzz? Если бы я у вас собеседовался и представил свое решение этой задачи. Удовлетворяет ли оно вашим требованиям?
Теперь само решение:
Сначала проведем анализ задачи и представим логику получения результата для числа N в виде таблицы решений:
+---------------------------------+-----------------+
| Conditions | Actions |
+----------------+----------------+-----------------+
| N is divisible | N is divisible | What to print |
| by 3 | by 5 | |
+================+================+=================+
| Yes | Yes | 'FizzBuzz' |
| +----------------+-----------------+
| | No + 'Fizz' |
+----------------+----------------+-----------------+
| No | Yes | 'Buzz' |
| +----------------+-----------------+
| | No + N |
+----------------+----------------+-----------------+
Теперь напишем реализацию таблицы решений на языке Python:
'''
FizzBuzz demonstration
'''
def fizz_buzz(n):
''' Evaluate FizzBuzz for the given n '''
isDivBy3 = n%3 == 0
isDivBy5 = n%5 == 0
if(isDivBy3 and isDivBy5):
result = 'FizzBuzz'
elif(isDivBy3 and not isDivBy5):
result = 'Fizz'
elif(not isDivBy3 and isDivBy5):
result = 'Buzz'
elif(not isDivBy3 and not isDivBy5):
result = str(n)
else:
raise Exception(f'Error processing number {n}')
return result
max_number = 100
for n in range(1, max_number + 1):
print(fizz_buzz(n))
Это напоминает мне прохождение ежегодного техосмотра машины в Голландии. Он у нас обязательный и для его успешного прохождения надо устранить все неисправности.
Лет 15 назад я прочитал статью в журнале общества автолюбителей. Они провели эксперимент: взяли машину, для которой были точно известны все ее неисправности, и отдали ее для прохождения техосмотра в 100 разных автосервисов. Результат: в большинстве гаражей нашли несуществующие неисправности и взяли деньги за их устранение.
То-то я удивлялся, что у меня каждый раз при прохождении техосмотра у дилера находили кучу проблем. Потом друзья посоветовали честный автосервис и я сразу стал платить меньше.
Я услышал в одном подкасте (кажется, здесь), что затраты работодателя в России для увольнения работника по сокращению штатов составляют примерно 3 месячные зарплаты этого работника (если он работает по ТК). То есть при увольнении по соглашению сторон следует договариваться о компенсации не ниже этой суммы.
Кстати, у нас в Голландии при увольнении по сокращении штатов работнику выплачивается компенсация в размере примерно месячной зарплаты за каждый проработанный год (во всяком случае, раньше так было).
Поэтому, например, если человек проработал 20 лет на одном месте, то его очень трудно сократить.
К тому, что, как работник FAANG, вы можете оценивать их систему найма только позитивно.
Прошу прощения. Я имел в виду "в FAANG".
Каждый кулик свое болото хвалит. Было бы странным, если бы человек, работающий в Google, написал что-то другое.
It depends. У нас в Голландии фото в резюме не добавляется, а в соседней Германии является обязательным.
Цитата из голландской книги, посвященной поиску работы:
Хотя эта книга была издана в 2004 и информация может быть устаревшей. Но подозреваю, что нет, учитывая консерватизм немцев.
Еще одно решение на Python с использованием механизма Pattern Matching:
Но, в отличие от Pattern Matching в C#, здесь нет проверки на логическую полноту условий. То есть, если убрать какое-либо из условий case, то не будет выдано никакого сообщения об ошибке.
Еще одно решение на Python с использованием словаря и лямбда-функций:
Почему завязли?
PL/I использовался очень широко (да и сейчас используется).
Например, в авиакомпании KLM PL/I являлся основным языком (COBOL тоже использовался). Я там проработал полтора года в конце 1990-х. Думаю, и сейчас они его активно используют.
И другие большие голландские компании (банки и т.д.) активно использовали PL/I.
В PL/I так же можно использовать встроенный SQL (для работы с СУБД Db2). И он лишен такого недостатка COBOL, как ужасный синтаксис.
Мне это напомнило, как в 1998 году я в течение 2-х недель без перерыва искал причины одного хитрого бага в системе планирования полетов авиакомпании KLM. Сидел за компьютером не вставая с утра до вечера.
И потом по итогам расследования написал 3 строчки кода, решив проблему.
P.S. Как вспомню, так вздрогну. На мейнфреймах не было отладчиков, и единственным способом отладки была расстановка операторов PRINT в коде программы. При этом вывод записывался в один из трех файлов (файл выбирался случайным образом). При этом параллельно в эти файлы писали еще десятки программ, так что найти результаты моей печати само по себе было проблемой.
.
А что это за язык? Какой-то shell?
Я бы так не сказал. Такое случается чаще, чем мы думаем.
Я уже после многих лет работы стал немного параноидальным и в этих случаях всегда бросаю исключение в последней ветке if. Точно так же я в операторе switch перечисляю все варианты и обязательно добавляю выброс исключения в ветке default.
В общем, как говаривал начальник Первого Отдела из института ИРЭ АН УССР, в котором я работал в советское время: "Лучше перебдеть, чем недобдеть".
Тут я подумал, что было бы неплохо, если бы компилятор сам проверял бы, что все условия написаны без ошибок (т.е. были бы исчерпывающе полными). Но с Python это точно не получится.
Может быть, это удастся сделать при помощи механизма Pattern Matching из последней версии C#? Я провел небольшое исследование, и получилось. Отпала необходимость в выбрасывании исключения, да и код стал выглядеть понятнее, чем написанный на Python:
Если здесь убрать одно из выражений из switch (например, первое), то Visual Studio выдаст предупреждение: CS8509 The switch expression does not handle all possible values of its input type (it is not exhaustive). For example, the pattern '(true, true)' is not covered.
Это предупреждение можно превратить в ошибку, и тогда код просто не скомпилируется (чтобы это сделать, нужно зайти в свойства проекта C#, раздел Build -> Errors and Warnings, секция Treat specific warnings as errors и внести в поле текст "CS8509").
.
.
Да
Это сделано специально. Догадываетесь почему?
Я давно занимаюсь Enterprise-программированием и мне часто приходится иметь дело со сложными бизнес-правилами. Так что решить такую простую задачку, как FizzBuzz, для меня будет несложно.
Я хочу у вас спросить, как у специалиста по FizzBuzz: какое ваше мнение по поводу моего решения для FizzBuzz? Если бы я у вас собеседовался и представил свое решение этой задачи. Удовлетворяет ли оно вашим требованиям?
Теперь само решение:
Сначала проведем анализ задачи и представим логику получения результата для числа N в виде таблицы решений:
Теперь напишем реализацию таблицы решений на языке Python:
Что вы думаете по поводу моего решения?
.
Это напоминает мне прохождение ежегодного техосмотра машины в Голландии. Он у нас обязательный и для его успешного прохождения надо устранить все неисправности.
Лет 15 назад я прочитал статью в журнале общества автолюбителей. Они провели эксперимент: взяли машину, для которой были точно известны все ее неисправности, и отдали ее для прохождения техосмотра в 100 разных автосервисов. Результат: в большинстве гаражей нашли несуществующие неисправности и взяли деньги за их устранение.
То-то я удивлялся, что у меня каждый раз при прохождении техосмотра у дилера находили кучу проблем. Потом друзья посоветовали честный автосервис и я сразу стал платить меньше.
Точно, с полом не все так просто. Вот, например, как определены коды для пола в стандарте ISO-5218 Representation of human sexes:
А в базах данных американского ФБР (Федеральное бюро расследований) используются следующие коды:
Информация взята из книги Ханс Ладани "SQL. Энциклопедия пользователя", 1998 год, издательство "Диасофт".