Заголовок выбран не случайно. Он отражает суть статьи, хоть и выглядит кликбейтом. Распространено мнение о неких "способностях" или "склонностях" к изучению языков. Я хотел бы внести технологию туда, где бытует мрак предубеждений и туманные указания из разряда "надо больше практики" и другие таинственные ответы на таинственные вопросы.

Система, описанная в статье, перевернет ваше представление об изучении языков. Я на это надеюсь. Но это случиться только если не спешить, читать внимательно и вдумчиво и связывать все тезисы между собой. Используйте систему 2 на полную катушку.

У функционального программирования есть одна большая проблема — о нем очень непросто рассказывать. Попытки донести людям что-то с использованием терминов типа «зигохистоморфный препроморфизм» легко сводят неподготовленного слушателя с ума.

Марк Симан — автор популярной книги Dependency Injection in .NET, автор бесчисленных блог-постов. На DotNext 2017 Moscow Марк рассмотрел применение dependency injection в классическом объектно-ориентированном дизайне и объяснил, почему его необязательно (даже нежелательно) использовать в функциональном программировании. Следом за этим он наглядно показал, как использование приемов функционального программирования устраняет необходимость в использовании моков и стабов в модульном тестировании и позволяет полностью выбросить мусор из прямого перечисления зависимостей.

Под катом — перевод доклада и видео. Далее повествование будет от лица Марка.

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

Начнем со сказки. Жил да был глагол( swim, jump, run… ), решил сменить пол, то бишь стать существительным. И превратился в герундий. И глаголом не остался, и существительным не стал. Получилось что-то непонятное, нечто среднее, скажем так: swimming, jumping, reading.

Мы это понимаем примерно так

swimming -плавание,

reading -чтение

jumping -прыжки.

То есть jumping -прыгание, как то язык не поворачивается сказать.

Но все эти примеры объединяет то, что они обозначают некий процесс. Какое-то занятие, полезное или не очень. Еще примеры в студию:

speaking, listening, reading, writing.

Переводиться все эти примеры будут по разному, в зависимости от ситуации. Нужно переставать заниматься прямыми переводами, а прежде всего знать, что обозначают глаголы, от которых эти герундии произошли. Другими словами понимать, когда льзя, а когда нельзя.

Многим хотелось бы знать, если вдруг что-то случится с их сайтом, магазином и т.п., особенно, если это не требует ни денег, ни времени, ни усилий. А ведь это довольно легко сделать: потратив совсем немного свободного времени, создадим докер контейнер, который будет периодически делать запросы в БД, расчитывать на их основании некие метрики, сравнивать их с пороговыми значениями и в случае превышения этих порогов, оповещать заинтересованных лиц.

В данной статье я хочу предоставить переработанную и упорядоченную выжимку документации по настройке tsconfig.json, которая, я уверен, будет полезна тем, кто только начинает свой путь в мире TypeScript или тем, кто до этого момента не нашёл времени и сил, чтобы разобраться в деталях и теперь хочет закрыть этот пробел.

Прошло шесть месяцев с тех пор, как мы анонсировали первую предварительную версию нового экспериментального редактора Razor для Visual Studio, основанного на общем языковом сервере Razor, и пришло время рассказать о наших успехах. Команда усердно работала над приведением нового редактора Razor в соответствие со старым, исправлением ошибок и добавлением множества замечательных новых функций. Мы думаем, что новый редактор близок к тому, чтобы быть готовым к нормальной повседневной разработке, поэтому сейчас самое время попробовать его с последней предварительной версией Visual Studio. Мы надеемся, что вы попробуете новый редактор Razor, и поделитесь с нами своими впечатлениями!

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

В этой статье я расскажу о тестировании кода с помощью Puppeteer — сервиса, который позволяет проверять работу скриптов в их естественной среде обитания — в браузере. Это не полноценный туториал по Puppeteer, а скорее набор советов о том, как писать осмысленные и стабильно работающие тесты.

Дисклеймер

• этот документ не является финансовым советом, прост личные мысли по поводу инвестиций, компаний
• почему я инвестирую в компании, а не крипту/недвиж/крышечки от пива (крипта, недвиж и крышечки у меня, конечно, есть): цель коммерческих компаний — зарабатывать деньги, цель валюты/крышечек — быть средством обмена, а недвиж/etc — заморозить $ где-то вокруг инфляции, ну или как-то так, я инженер, а не экономист, сильно не бейте ¯*(ツ)*/¯
• мои принципы инвестирования оч простые:

В этом году поучавствовал в соревновании по написанию игровых ботов Russian AI Cup. И хоть не удалось взять 1е место, как в 2017, но все равно это было увлекательное и невероятно азартное приклюение длинной в месяц, полное напряженного кодинга, недосыпания, творческих озарений и интриг в финале. Сразу оговорюсь, что в стратегии не использовался AI в современном понимании, с нейронными сетями и прочим - только алгоритмы и структуры данных. Мыслей накопилось много, поэтому приготовьтесь к длинному чтению..

Представьте себе ситуацию, что вы вызвали Яндекс.Такси, а водитель увёз вас в лес, ограбил и бросил там. После оказалось, что и водительских прав-то у него нету. Вы звоните в тех поддержку, связываетесь с руководителями разного уровня сервиса Яндекс, чтобы получить их мнение о случившемся или хотя бы услышать сочувствие, сопереживание, что такое случилось в их сервисе, а они по очереди вам говорят - этот водитель профессионал, он прошёл дополнительное обучение, ваша поездка прошла по высшему классу, простите, что машина была без желтых номеров, как вы заказали. И да - деньги вам вернут только частично, потому что машина ехала, бензин и время водителя тратились, в лес вас все таки завезли.

Хотите такое ощутить? Тогда велкам в Яндекс.Практикум на курс «Алгоритмы для разработчиков».

Имеем: проект web API на .net core с исходниками в GitHub.

Хотим: авторазвертывание на виртуалке AWS EC2 после завершения работы с кодом (для примера push в develop ветку).

Инструментарий: GitHub Actions, AWS CodeDeploy, S3, EC2.

Ниже flow процесса, который будем реализовывать, погнали.

Да, вы не ослышались – именно так! В IT-сообществе прочно укоренилось мнение, что все эти тесты вам хоть как-то помогают, но так ли это на самом деле? Вы сами пробовали мыслить критически и анализировать это расхожее мнение? Хипстеры придумывают кучу парадигм – TDD, BDD, ПДД, ГИБДД – лишь чтобы создать иллюзию бурной деятельности и хоть как-то оправдать свою зарплату. Но задумайтесь, что будет, если вы (либо ваши программисты) начнете все свое время уделять исключительно написанию кода? Для тестирования есть отдельное направление и целые подразделения. Вы же не заставляете программистов писать требования, так? Тогда почему они должны писать тесты? Всех согласных и несогласных прошу проследовать внутрь поста, где я вам наглядно покажу, что юнит (и интеграционные) тесты – великое зло!

Все знают, что вода с маслом не смешивается.

Кто помнит школьную физику, легко назовёт третью жидкость, не смешивающуюся с этими двумя: ртуть.

Вопрос: а сколько всего известно взаимно нерастворимых жидкостей при условиях, близких к нормальным?

Авторы этой работы собрали семь. Правда, повторять их опыт дома решительно не хочется, ибо в списке ингредиентов присутствуют анилин, ртуть, и такая "прелесть", как расплавленный (!) белый фосфор. Чертовски горючий, ядовитый, заслуженно полагаемый за это сочетание оружием, заставляющий вновь помянуть урановые ломы в ртути...

Тогда вопрос №2: а сколько можно найти взаимно несмешиваемых жидкостей, которые не страшно принести домой, чтобы показать демку детям?

Мне удалось собрать пять. Собственно, их сливанием вот в эту пробирку мы в статье и займёмся.

Поехали?

Этой статья раскрывает концепции Middleware в ASP.NET Core. К концу этой статьи вы получите четкое представление о следующих моментах:

- Что такое Middleware?

- Почему порядок расположения Middleware имеет значение?

- Методы Run, Use и Map.

- Как создать собственное Middleware?

- Как реализовать просмотр каталогов с помощью Middleware?