Тут только первая часть статьи с новыми новостями. (Изменение 8.03.2021)
Создание собственного сайта провалилось. Большинству не интересен коронавирус.
Из принципа буду продолжать менять только новости и таблицу.
Прошло больше года с написания этой статьи. Итог:: Мои надежды не оправдались.
Полная версия без обновлений новостей тут
Не обновляемая английская версия: тут

Независимые от меня обстоятельства повлияли на текущую ситуацию, мои извинения

Перейти сразу к новостям

Многие люди не выполняют рекомендаций.Все пошло по «тяжелому сценарию». У систем здравоохранения есть куда увеличивать количество коек, врачей:
Качество: Высокое
1уровень: Инфекционные койки. 10-20% ## Инфекционисты

Качество: Среднее
2уровень: Перепрофилирование больниц 30-60% ## Любые врачи. Возвращают врачей пенсионного возраста.

Качество: Удовлетворительное
3 уровень Частные клиники и военные госпитали 10-20% ## все врачи даже без опыта, снятие из институтов. Военврачи.

Качество: Низкое
4 уровень: Временные больницы 10-20% (Обычно отправлять больных в более легкой форме.Более тяжелые будут в больницах) ## Быстро обученный персонал. (Будут давать более простые задачи, разгрузка врачей от пары задач). Альт. вариант армия для выполнения части задач.

Китай было:2 из 4 /4 из 4 (временные больницы)Италия: Врачи: по 3 из 4.
Качество: Абсолютное (Не бойтесь 5lvl. придумал я, до этого не дойдет)Сарказм: 5 ур.: Больницы не понадобятся.Подробно Dr. Morty.
Статистикshorturl.at/pEY09

О чем эта статья

Немного истории, истоков и революции

Как я писал в предисловии предыдущей статьи, я нахожусь в поисках языка, в котором я мог бы писать поменьше, а безопасности иметь побольше. Моим основным языком программирования всегда был C#, поэтому я решил попробовать два языка, симметрично отличающиеся от него по шкале сложности, про которые до этого момента приходилось только слышать, а вот писать не довелось: Haskell и Go. Один язык стал известен высказыванием "Avoid success at all costs"*, другой же, по моему скромному мнению, является полной его противоположенностью. В итоге, хотелось понять, что же окажется лучше: умышленная простота или умышленная строгость?

Я решил написать решение одной задачки, и посмотреть, насколько это просто на обоих языках, какая у них кривая обучения для разработчика с опытом, сколько всего надо изучить для этого и насколько идиоматичным получается "новичковый" код в одном и другом случае. Дополнительно хотелось понять, сколько в итоге мне придется заплатить за ублажание хаскеллевского компилятора и сколько времени сэкономит знаменитое удобство горутин. Я старался быть настолько непредвзятым, насколько это возможно, а субъективное мнение приведу в конце статьи. Итоговые результаты меня весьма удивили, поэтому я решил, что хабровчанам будет интересно почитать про такое сравнение.

Функциональное программирование — это очень забавная парадигма. С одной стороны, про неё все знают, и все любят пользоваться всякими паттерн матчингами и лямбдами, с другой на чистом ФП языке обычно мало кто пишет. Поэтому понимание о том, что же это такое восходит больше к мифам и городским легендам, которые весьма далеко ушли от истины, а у людей складывается мнение, что "ФП подходит для всяких оторванных от жизни программок расчетов фракталов, а для настоящих задач есть зарекомендовавший себя в бою проверенный временем ООП".

Хотя люди обычно признают удобства ФП фич, ведь намного приятнее писать:

int Factorial(int n)
{
    Log.Info($"Computing factorial of {n}");
    return Enumerable.Range(1, n).Aggregate((x, y) => x * y);
}

чем ужасные императивные программы вроде

int Factorial(int n)
{
    int result = 1;
    for (int i = 2; i <= n; i++)
    {
        result *= i;
    }
    return result;
}

Так ведь? С одной стороны да. А с другой именно вторая программа в отличие от первой является функциональной.

Как же так, разве не наоборот? Красивый флюент интерфейс, трансформация данных и лямбды это функционально, а грязные циклы которые мутируют локальные переменные — наследие прошлого? Так вот, оказывается, что нет.

Содержание

Именно таким вопросом я задался, когда будучи простым физическим лицом и гражданином РФ, устроился на удалённую работу разработчиком ПО в одну иностранную компанию и начал получать заработную плату валютой из-за рубежа. Порывшись в Сети на предмет возможностей легализации своего дохода не нашёл чётких и точных ответов и руководств. Пришлось искать информацию самому. Результатами своих изысканий я и хочу поделиться со всеми.

Сразу пишу к чему пришёл в ходе изысканий:

1. ИП на ПСН
2. поступление оплаты за услуги по разработке ПО на счёт ИП в долларах США
3. основание для оплаты инвойс, сумма которого не превышает 200 000 руб.
4. инвойсы выставляются по-мере необходимости
5. ККТ не используется

То есть, спокойно работаю, в конце оговоренного периода формирую инвойс, в котором указываю согласованную с работодателем сумму не превышающую указанный порог, получаю деньги прямо на расчётный счёт, оплачиваю раз в год или в течение года патент и взносы в размере 54 000 рублей и больше не переживаю о том, что завтра злобные налоговики придут ко мне с повесткой и ужасными новостями (это была минутка юмора). В следующем году эта сумма подрастёт до 60 000 рублей за год.

Почему так? Какие могут быть ещё варианты? Чем плохи для меня Upwork, PayPal и Payoneer? Попробую ответить под катом. Кому интересны все эти детали, читаем дальше :-)

Performance in .NET Core

ToList vs ToArray and Cycles

Оглавление

Предисловие

— Работа программистом-разработчиком — тяжелый труд, сравнимый с валкой леса топором. И проблематика данного труда сильно недооценена в общественном сознании.

Недавно мне повезло пообщаться с Крисом Бэйконом, который написал DotNetAnywhere (альтернативный вариант .NET Runtime), и я остроумно заметил:

… ты, наверное, один из тех немногих, кто создал собственную среду выполнения .NET, и это круто!

если исключить тех, кто на зарплате, т.е. инженеров Microsoft/Mono/Xamarin, их очень немного.

Это — перевод статьи Matt Warren (A History of .NET Runtimes). Дабы не делать повторную публикацию, оставлю as is

Необходимое вступление

Я не гарантирую, что изложенные здесь трактовки общепринятых терминов и принципов совпадают с тем, что изложили в солидных научных статьях калифорнийские профессора во второй половине прошлого века. Я не гарантирую, что мои трактовки полностью разделялись или разделяются большинством IT-профессионалов в отрасли или научной среде. Я даже не гарантирую, что мои трактовки помогут вам на собеседовании, хоть и предполагаю, что будут небесполезны.

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

Столь малые гарантии поднимают вопросы о причинах, по которым статья пишется. Я считаю, что этим вещам должны учить везде, где учат программированию, вплоть до уроков информатики в школах с углублённым её изучением. Тем не менее, для меня стала пугающе нормальной ситуация, когда я узнаю, что собеседник мой коллега, причём работающий уже не первый год, но про инкапсуляцию «что-то там слышал». Необходимость собрать всё это в одном месте и давать ссылку при возникновении вопросов зрела давно. А тут ещё и мой «pet-project» дал мне изрядно пищи для размышлений.

Тут мне могут возразить, что учить эти вещи в школе рановато, и вообще на ООП свет клином не сошёлся. Во-первых, это смотря как учить. Во-вторых, 70% материала этой статьи применимо не только к ООП. Что я буду отмечать отдельно.

^{Комментарий модератора. Эта статья находилась в Песочнице и была отклонена на премодерации. Но сегодня был поднят важный и сложный вопрос в статье. А этот пост раскрывает признаки распада личности и может быть полезным тем, кто, как выразился автор упомянутой статьи, в метре от водопада. Поэтому решено её выпустить.}