В статье представлен код позволяющий отправлять транзакционные письма через сервис unione, делать HTTP запросы к REST апи, а так же отправлять обычные email по smtp используя общий класс отправитель различных сообщений.
Первое мое знакомство с Mobx началось с удивления. Я не понимал всю магию библиотеки и задавал себе вопрос: “А как это возможно?”. Кажется, в ней используются какие-то подкапотные возможности JS или Mobx вообще написан на другом языке.
И вот, потратив 3 месяца в исходниках, я развеял для себя магию. Mobx все таки написан на JS и даже имеет множественные ограничения, которые нужно соблюдать, чтобы ваш браузер не взорвался.
В этой статье мы создадим свой Mobx с нуля, а так же свяжем его с React, через собственно написанный HOC observer. В конце у вас будет общее понимание реактивности, которое поможет в самостоятельном осмыслении не только Mobx, но и других реактивных библиотек и фреймворков.
Для python существует множество различных библиотек, но часто бывает, что для конкретного проекта функционал какого-либо пакета - избыточен. В большинстве случаев необходимо вызывать лишь несколько постоянно повторяющихся методов, да и часть их аргументов не меняется от вызова к вызову.
В относительно простом приложении проблему константных аргументов можно решить при помощи functools.partial или вообще поместить повторяющийся код в отдельную функцию, но что, если даже в этом случае код со временем становится все более запутанным и сложным для читаемости?
На мой взгляд, неплохим выходом из ситуации служит использование объектно-ориентированного подхода, а именно написание некого класса "обвязки" с более простыми методами, инкапсулирующими в себе сложную логику обращения к оригинальной библиотеке.
Вы задумывались, что такое объект? Что-то из реального мира: человек, машина, здание? Почему?
Я тоже так думал. Это меня ограничивало. Но затем я понял одну вещь. Эта вещь не только помогла продвинуть мое мышление ближе к объектно-ориентированной парадигме, но и писать лучший код.
Хочу поделиться своим ООзарением с вами.
В данной статье мы бы хотели описать использованный нами ООП подход к отправке писем через данный сервис рассылок на php. Суть которого заключается в создании объекта инкапсулирующего данные необходимые для отправки письма и методы работы с ними. Кажется что это довольно простая идея, но нам не встречалось ещё в доступных источниках такого подхода, поэтому хотим внести свой вклад в этом направлении. Тем не менее статья написана не для того чтобы пропагандировать данный подход. Она написана с целью развития компетенций в области ООП и способности его использования практических задач, будь то отправка писем или ещё что-то.
В статье присутствуют материалы, о которых обучающимся программированию рассказывают в самом начале. Когда я преподавал в GeekBrains, первый месяц курса по PHP был посвящен синтаксису, а вот второй как раз тем темам, о которых я буду говорить здесь. К сожалению, не помню, когда мне их преподавали в институте во время моего обучения на программиста, но, наверное, тоже где-то на первых курсах.
Во время подготовки этой статьи я опирался на свой опыт и на отрывки запомнившихся статей и книг. Здесь я выражаю только лишь свое мнение, с которым, конечно же, вы вправе не соглашаться. Любая критика, особенно конструктивная, приветствуется.
Цель статьи: напомнить нам, разработчикам, об основах и мотивировать нас уделять больше времени базовым, академическим знаниям и опыту наших предшественников. Они действительно помогают писать код лучше. Вовремя прочитанная книжка может сэкономить несколько лет неосознанных повторений своих же решений.
Программировать нужно осознанно.
MediatR - это очень популярная библиотека, которая используется для уменьшения зависимостей между объектами. Она популяризует архитектуру, основанную на крайне значимых принципах проектирования:
• препятствование прямому общению между объектами для уменьшения связности;
• нацеливание на Message-Oriented архитектуру;
• поддержка асинхронного внутреннего обмена сообщениями;
• ориентирование на переиспользование объектов.
Эти практики не пустое слово для меня. Кроме того, кажется, что такой способ создания программного обеспечения должен быть совершенно очевидным. Без сомнения, библиотека MediatR очень успешна и широко применяется разработчиками, которые разделяют эти ценности.
Существует множество статей о MediatR, но лишь их малая часть фокусируется на недостатках и помогает определить случаи, когда использование инструмента не имеет смысла. Этот пост один из таких.
В этой статье хочу поговорить о том когда и почему применение MediatR может не оправдать ожиданий. В частности, думаю, что, несмотря на добрые намерения, некоторые способы внедрения MediatR могут причинить вред в погоне за лучшими архитектурными практиками и даже привести к использованию анти-паттернов.
Также стоит отметить, что эта статья не покрывает положительные аспекты библиотеки, а фокусируется только на недостатках.
Это не про функции!
В программировании есть два больших подхода — императивное и функциональное. Они существенно отличаются логикой работы, ещё и создают путаницу в названиях. Сейчас объясним.
Нет. Функциональное — это не про функции. Функции есть почти в любых языках программирования: и в функциональных, и в императивных. Отличие функционального программирования от императивного — в общем подходе.
Метафора: инструкция или книга правил
Представьте, что вы открываете кафе-столовую. Сейчас у вас там два типа сотрудников: повара и администраторы.
Для поваров вы пишете чёткие пошаговые инструкции для каждого блюда.
Это история о том, как потерпеть фиаско, имея хорошо написанный и протестированный в боевых условиях работающий код и даже написанную документацию. Изначально я собирался делать анонс своей библиотеки, но что-то пошло не так. Поэтому начнём за здравие -- постановка и формализация задачи, описание возможностей и батареек. А закончим за упокой -- вопросами, как всё это теперь тестировать?
MediatR является, безусловно, очень успешным и популярным open-source проектом, который глубоко проник в недры коммерческой разработки. Однако, сколь популярен инструмент столь много способов его применения рождается среди сообщества. В этой статье я покажу два самых главных способа использовать этот инструмент неправильно вместе со способами решения проблемы
Количество классов в реализации даже небольшой программы на один человеко-месяц исчисляется десятками. В средних программах на несколько человеко-лет счёт идёт уже на тысячи. А человек может одновременно оперировать 7-ю +/- 2 объектами. Поэтому все нетривиальные программы требуют декомпозиции своей реализации на более крупные блоки, чем классы - я буду называть такие блоки пакетами.
Сейчас наиболее распространены два основных подхода к декомпозиции систем: пакетирование по слоям и техническим аспектам (далее просто "по слоям" для краткости) и пакетирование на основе предметной области (представленное группой вариантов: пакетирование по фичам, пакетирование по компонентам, ограниченные контексты и пакетирование по агрегатам из предметно-ориентированного дизайна (DDD))
Однако ни один из этих подходов мне не подошёл в полной мере и я изобрёл… объектно-ориентированный подход к декомпозиции систем. Точнее, я изобрёл простую методику выполнения декомпозиции, а потом понял, что на выходе она даёт штуки обладающие свойствами объекта.
Но обо всём по порядку - сначала я рассмотрю критерии оценки подходов, распространённые подходы и почему они мне не подошли. А закончу пост представлением методики выполнения объектно-ориентированной декомпозиции.
Месяц назад вышел новый стандарт ECMAScript 2022, который нам дал всё больше и больше ООП. На Хабре уже была статья про то, что нам представили в новом стандарте, но сегодня я хочу остановиться на том, что мы не получили. Приватные конструкторы в студию.
Разберём, что такое приватные конструкторы, зачем они нужны и попробуем создать полифил.
Во многих источниках тип double и float, числа с плавающей запятой/точкой зачем-то называют вещественными. Такое чувство что кто-то когда-то совершил ошибку или не внимательно написал эту глупость и все как один начали её повторять, совершенно не задумываясь о чём они говорят.
Ладно это были бы просто троечники студенты и любители, так эту ошибку говорят и те, кто обучают специалистов. И эта проблема терминологии не одного ЯП, их правда много (Java, C++, C#, Python, JS и т.д.) везде, где бы я не искал, всегда находятся статьи, ответы, лекции, где дробные числа называют вещественными!
Sanic - современный мощный фреймворк, незаслуженно обделённый вниманием российского IT-сообщества.
