.NET
Автор Лысый Камрад (@LKamrad)
Если вы считаете выборы президента США через коллегии выборщиков малопонятными и необоснованно усложненными, то уверен — попытка понять смысл порядка выбора главы венецианской республики (дожа) погрузит вас в пучину когнитивного диссонанса, даже если вы не подозреваете, что это такое.
Читать на английском – интересно и полезно. Однако, многолетнему обитателю рунета непросто найти хорошие иностранные ресурсы. Плюс, многое из найденного оказывается скучным или слишком сложным. Я постарался подобрать интересные сайты для практики английского и понять, какие из них имеют доступный уровень сложности, а какие – более 9999999.
На выходе получился список сайтов размеченных по уровню сложности: легко, средне, сложно, очень сложно. Список разбит на 6 форматов: расшифровки подкастов, интервью, площадки для общения, новости и статьи, книги, обучающие тексты.
В какой-то момент у нас стало много хотфиксов — стабильно больше половины деплоев на проде были хотфиксы или откаты. Мы решили анализировать каждый хотфикс, чтобы понять причины, найти системные закономерности и устранить их, не допуская два раза одних и тех же ошибок. Как говорил Джейсон Стейтем (Стэтхэм? Стэтэм?): «Не страшно ошибаться, страшно повторять одну ошибку 2 раза». Ну и мы решили не повторяться и внедрить постмортемы. В статье расскажу как мы анализируем хотфиксы и другие критичные проблемы, что у нас получается, а что нет, с какими сложностями столкнулись и как их решали.
Допустим, вы интересуетесь космосом, но космос для вас недоступен. Выше 10км не подняться, а посмотреть "что там?" очень хочется. По классификации NASA — нижняя граница космоса начинается на 100км от поверхности Земли. Эта статья будет не совсем про космос, но про возможность создания своего стратосферного зонда с нуля. Я много видел примеров успешного запуска и несколько статей на Хабре, но почти все они — это отчеты. Я же хочу оставить статью, которая сможет претендовать на "complete guide" для юных покорителей. Запаситесь терпением и безлимитным интернетом — будет много текста, картинок и даже пару видео. Это был долгий путь для нас, но я намерен сделать его не таким изнурительным для всех желающих. Поехали?
Как и CSS Grid, Flex Box довольно сложен, потому что состоит из двух составляющих: контейнера и элементов внутри него.
Когда я начал изучать Flex, я хотел увидеть все, на что он способен. Но мне не удалось найти подробное руководство с примерами всех возможностей. Поэтому я решил самостоятельно создать диаграммы свойств Flex с «высоты птичьего полета».
Эта статья содержит рекомендации по написанию Dockerfile и принципам безопасности контейнеров и некоторые другие связанные темы, например про оптимизацию образов.
Если вы знакомы с контейнеризованными приложениями и микросервисами, то скорее всего понимаете, что хотя ваши сервисы "микро", но поиск уязвимостей и устранение проблем с безопасностью способен затруднить управление вашими сервисами, уже с приставкой "макро".
К счастью, большинство потенциальных проблем мы можем решить еще на этапе разработки.
Хорошо подготовленный Dockerfile исключает необходимость использовать привилегированные контейнеры, открывать порты, в которых нет необходимости, включать лишние пакеты и избегать утечки чувствительных данных. Старайтесь решить эти проблемы сразу, это поможет в дальнейшем сократить усилия на поддержку ваших приложений.
Меня раздражает традиционная архитектура бизнес-приложений — об этом я уже говорил. Я критикую — я предлагаю. Сейчас я расскажу, к чему меня привели поиски решений для проблем из предыдущей статьи.
Мне нравится перебирать архитектурные концепции. Всю жизнь я пытаюсь найти в области архитектуры и дизайна ПО что-то работающее и в то же время простое. Не требующее разрыва мозга для понимания и кардинальной смены парадигмы. Идей накопилось порядочно и я решил объединить лучшие из них в своём фреймворке — Reinforced.Tecture. Разработка таких штук даёт гигантское количество пищи для размышлений, я хочу ими поделиться.
Тексты про такие технические вещи обычно до ужаса нудные. Я честно постарался не нудить, поэтому мой текст получился слегка агрессивным. Если вам с этим норм и интересно почитать про архитектуры .NET-приложений — заходите.
Представляю вашему вниманию перевод статьи The Magical Methods in C# автора CEZARY PIĄTEK.
Есть определенный набор сигнатур методов в C#, имеющих поддержку на уровне языка. Методы с такими сигнатурами позволяют использовать специальный синтаксис со всеми его преимуществами. Например, с их помощью можно упростить наш код или создать DSL для того, чтобы выразить решение проблемы более красивым образом. Я встречаюсь с такими методами повсеместно, так что я решил написать пост и обобщить все мои находки по этой теме, а именно:
В предыдущей статье мы обсуждали, почему функциональное программирование это совсем не то, что распиарено, и что оно совершенно не противоречит ООП, так, что даже сам "Дядя Боб" пишет про хороший ФП дизайн порождающий хороший ООП дизайн программы (и наоборот).
Сейчас же я хочу рассказать, что такое монады на самом деле, чем они полезны для обычного практикующего разработчика, и приведу примеры, почему недостаточная поддержка их в распространенных языках приводит к копипасте и ненадежным решениям.
Но ведь в интернете буквально сотни статей про ФП и монады, зачем писать еще одну?
Дело в том, что все их (по крайней мере те что я читал) можно поделить условно на две категории: с одной стороны это статьи где вам объяснят что монада это моноид в категории эндофункторов, и что если монада T над неким топосом имеет правый сопряжённый, то категория T-алгебр над этой монадой — топос. На другой стороне располагаются статьи, где вам рассказывают, что монады — это коробки, в которых живут собачки, кошечки, и вот они из одних коробок перепрыгивают в другие, размножаются, исчезают… В итоге за горой аналогий понять что-то содержательное решительно невозможно.
Получается, что первые обычно полезны тем, кто и так знает обсуждаемую тему, а вторые даже не знаю на кого рассчитаны: сколько я их не прочитал, ничего полезного понять из них мне не удалось.
Я же хотел бы занять промежуточную позицию, и рассказать про монады без заумных терминов, но и без котиков, используя понятные ООП разработчикам термины: интерфейсы, паттерны, копипаста, инкапсуляция сложности, бойлерплейт, и так далее. В процессе работы над статьёй ни один термин теории категории использован не был.
