Привет! Меня зовут Андрей Татаренко, я работаю Data Scientist-ом в Альфа-Банке. Я вам расскажу о своем опыте разработки Python-библиотеки для автоматизации разработки типовых ML-моделей. В статье привожу ту структуру основных классов, которая у меня получилась. Надеюсь, читатель сможет почерпнуть какие-то идеи, особенно если уже сталкивался с подобной задачей.
ООП *
Объектно-ориентированное программирование
Новости
Kotlin для Самых маленьких
В этой статье я научу вас основам Kotlin. Начиная с самого начала мы дойдем до уверернного уровня использования Kotlin. Чтоб когда у вас спросили "Как сделать лямбду функцию" вы на лбу спросившего написали:
Типы в программировании как математические множества
Типы в программировании можно(и нужно) рассматривать как математические множества.
Мысль хоть и очевидная, но из моей головы давно выветрилась.
Именно поэтому я и решил написать эту статью: чтобы напомнить о ней самому себе и тем, кто о ней тоже забыл или даже не знал.
Почему микросервисы лучше компонент или как деградируют идеи в IT
Попробуем начать с цитаты:
При современных темпах развития индустрии программирования приложениям нельзя оставаться застывшими. Разработчики должны найти способ вдохнуть новую жизнь в программы, которые уже поставлены пользователям. Решение состоит в том, чтобы разбить монолитное приложение на отдельные части, или микросервисы (рис. 1).
...
Традиционно приложение состояло из отдельных файлов, модулей или классов, которые компилировались и компоновались в единое целое. Разработка приложений из микросервисов — так называемых приложений микросервисной архитектуры — происходит совершенно иначе. Микросервис подобен миниприложению; он поставляется пользователю как двоичный код, скомпилированный и готовый к использованию. Единого целого больше нет. Его место занимают специализированные микросервисы, которые подключаются во время выполнения к другим микросервисам, формируя приложение. Модификация или расширение приложения сводится просто к замене одного из составляющих его микросервисов новой версией.
Если интересно откуда эта цитата и что с ней не так прошу под кат.
Истории
Немного про DDD: Реализация событий предметной области в .NET
Всем привет! Предметно-ориентированное проектирование, на мой взгляд, является недопонятым подходом, о котором многие говорят, но немногие его действительно применяют.
Одним из относительно простых в реализации и полезных в архитектурном смысле паттернов, на мой взгляд, являются события предметной области (Domain Events). В данной статье я бы хотел рассказать о возможных вариантах реализации этого шаблона DDD с использованием .NET.
Вот здесь точно нужен рефакторинг, есть идеи?
Бывают пет-проекты, а у нас получился проект с наработками, которые вроде бы могут быть полезны например студентам технических специальностей и просто всем кому интересно поразбираться с возможностями визуализации на C# + WPF, например, или с системой избыточного кодирования.
Мы со студентами сделали приложение для анализа характеристик LDPC кодов изначально на Java (Java код тоже присутствует в репозитории) потом я переписал его в виде проекта C# + WPF, чтобы добавить возможность конфигурации статистических экспериментов через визуальный интерфейс, а главное чтобы иметь возможность визуализации результатов экспериментов в виде графиков (обычных, в X, Y осях). Я как раз для работы сделал библиотеку для рисования обычных математических графиков по массивам значений с возможностью масштабирования области просмотра мышкой.
Думаю студентам любых технических направлений может пригодиться такая библиотека при том, что весь ее достаточно компактный исходный код (5-7 файлов) локализован в проекте и доступен как для изучения так и для любых изменений и доработок.
Под катом ссылка на Гит-репозиторий с исходным кодом и обзор реализованной функциональности со скриншотами.
Паттерн «Интерпретатор»: что такое и как использовать
Привет, хабровчане!
Я Дима, Python-разработчик из 21YARD, сервиса поиска строительных подрядчиков.
В статье расскажу о паттерне Интерпретатор. Разберемся, когда его использовать, какие концепции лежат в его основе. После используем паттерн, чтобы написать программу для решения математических выражений.
Немного курочим стандартный валидатор Laravel или первый опыт с фасадами и сервис провайдерами
Статья про то, как я изменил стандартное поведение нормализации ввода и решил проблемы валидации, возникшие из-за этого. В статье упоминаются слова ООП, наследование, фабрики, сервис-провайдеры и другие.
Рефакторим легаси при помощи ООП
Спустя годы проекты обрастают тёмными местами, в которые никто не хочет соваться, поскольку их сложно понять и легко сломать. Сегодня мы посмотрим на кейс рефакторинга такого кода с переводом на ООП рельсы при помощи паттернов, причём со стилем (современным).
Как сменить технологию и не закопаться в рефакторинге: опыт внедрения DDD в проект на FastAPI — Часть 2
Привет, хабравчане!
В первой части были рассмотрены паттерны проектирования Repository и Unit of Work.
Это вторая часть цикла о DDD. В ней расскажу, как добавить к проекту событийно-ориентированную архитектуру.
Код подопытного приложения ищите в репозитории по ссылке. Подробнее о DDD и паттернах Repository и Unit of Work читайте в первой части по ссылке...
Kotlin глазами Java-разработчика
Привет, хабр! Сегодня я хочу рассказать про свой опыт взаимодействия с языком kotlin.
Представлюсь – я java разработчик, работаю в крупном банке, создаю (и поддерживаю существующие) микросервисы.
Небольшая ремарка: я не собираюсь становиться Android разработчиком, ни сейчас, ни в будущем, поэтому, когда я заинтересовался новым языком, не принимал в расчет аргументы про различные удобства мобильной разработки на нем, и руководствовался только удобством языка в целом для бэкэнда.
Итак, почему я решил изучить kotlin. Ну, во-первых, прожужали все уши, мол сокращение объема код, лаконичность, читаемость и сахар.
Что будет, если скрестить конструирование компиляторов, DDD и Clean Architecture? Опыт HydraScript
В этой статье я расскажу о двухлетнем эксперименте, проводимом над моим пет-проектом, интерпретатором ЯП HydraScript. Почему к разработке из области системного программирования были применены промышленные практики, и зачем конструированию компиляторов нужен Domain Driver Design с чистой архитектурой?
Исходники проекта
Сериализация сущностей с помощью декораторов на TypeScript
В процессе написания приложения с более-менее сложной бизнес-логикой на фронтенде возникает необходимость держать всю эту логику на слое предметной области в "толстых" моделях. Например, для работы с формой, которая отображает на пользовательский интерфейс создание или редактирование сущности с большим количеством взаимозависимых свойств. Если "размазать" обработчики изменения состояния этой сущности и входящих в неё подсущностей по слою Application, легко можно потерять целостность модели в разных actions, reducers, валидаторах. Такой код будет трудно читать, отлаживать и поддерживать.
Можно использовать паттерн Aggregate Root для единой точки входа управления моделью, тогда упростится поддержка инварианта такой сущности. Методы доступа к свойствам и методы, меняющие состояние сущности, можно вызывать из одного объекта, а сам объект будет обеспечивать целостность и валидность своих данных. Но здесь появляется ещё одна проблема: сериализация. К примеру, бывает нужно сохранить всю сущность в каком-нибудь хранилище -- localStorage, redux store. Или отправить на бэкэнд для сохранения. Или событием обновить пользовательский интерфейс, а в payload события при этом надо передать часть сущности в виде простого плоского объекта. В этих случаях нам нужна выжимка данных из сущности, которую можно будет восстановить потом при запросе из хранилища для дальнейшей работы. Это особенно актуально, если на проекте используется SSR, там данные, которые собираются для страницы на серверной стороне, должны быть сериализуемыми.
Ближайшие события
Key-Value Хранилище на Стероидах
Как абстрагироваться от Key-Value хранилища и забыть про бойлерплейт внутри репозиториев с помощью Kotlin делегатов
Истоки ООП
Статья посвящена теме ООП, истоков его создания и пояснения почему его стоит применять.
История начинается с того, что создатель ООП, Алан Кёртис Кэй, получил степень бакалавра по молекулярной биологии. Его интерес вызывали клетки организмов, их строение и поведение. Собственно чтобы не изобретать велосипед и использовать лучшие практики природы им и был создан этот подход к программированию, ООП.
Все ООП это попытка описать поведение клеток между друг другом, отсюда и энные принципы.
ООП не определяет архитектуру проекта
Изначально этот материал планировался как урок в PHP-курсе по полиморфизму. Но он, в конце концов, перерос сам урок, и я решил сделать из него отдельную статью. В ней практически ничего PHP-специфичного, поэтому рекомендуется для прочтения всем без исключения.
Напомню, что модель классов PHP взята из Java. Наличие интерфейсов и всех сопутствующих элементов очень сильно влияет на способ организации кода в PHP. Этот способ часто отличается от того, как организуется код в JavaScript, Ruby или Python. И ещё больше отличается от таких языков, как Clojure или Elixir. И всё это на фоне того, что в каждом из этих языков есть ООП.
ООП в этих языках настолько разное, что PHP-программисты, попадающие в Ruby или JavaScript, не понимают, как так можно писать, ведь многие подходы противоречат их представлениям о мире. То же самое происходит и в обратной ситуации.
Так где же правда? Правда в том, что есть вещи, которые действительно определяют архитектуру кода. И это не структура классов, не наличие интерфейсов и не использование полиморфизма.
Возьмём тот же MVC. В нём говорится о слоях, об их задачах (зонах ответственности) и способе взаимодействия друг с другом. Это крайне важно для модульности. В модульной системе отсутствуют циклические зависимости. В MVC ничего не говорится про классы и ООП в целом, потому что между этими понятиями нет связи. Реализовать MVC можно в любом языке общего назначения, каким бы он ни был. То же самое можно сказать обо всех других архитектурных шаблонах.
Архитектура опирается на особенности среды, в рамках которой она применяется, а не на конструкции языка. Например, в вебе господствует HTTP, который построен вокруг концепции "запрос-ответ". Именно поэтому микрофреймворки разных языков выглядят так похоже, независимо от того, есть там ООП или нет: в каждом микрофреймворке есть запрос, ответ и обработчик ответа.
Подробнее о разработке я пишу в своем телеграм-канале организованное программирование. Присоединяйтесь если статья понравилась :)
Как сменить технологию и не закопаться в рефакторинге: опыт внедрения DDD в проект на FastAPI — Часть 1
Привет, хабравчане!
В серии статей расскажу, что такое DDD (domain-driven design) и какие у него преимущества и недостатки. Разберемся, когда применять подход и как сочетать его с FastAPI, популярным ASGI фреймворком на Python.
В этой части рассмотрим паттерны проектирования Repository и Unit of Work. С их помощью мы работаем через интерфейсы. Паттерны помогают в разделении кода на слои: основная логика приложения представляется внутренними слоями, а используемые технологии - внешними.
Инверсия управления Контейнеров и паттерн Инъекции Зависимостей — перевод
В основе сборки любых компонентов лежит общий шаблон того, как они выполняют прокидывание зависимостей, это концепция, которую разработчики называют очень общим именем Inversion of Control (IoC: инверсия контроля). В этой статье я углублюсь в то, как работает этот паттерн под более конкретным названием «Dependency Injection» (Инъекция зависимостей), и сравню его с альтернативой - Service Locator
Форматирование строк в Python
В мире программирования, особенно при разработке на Python, часто возникает необходимость не просто выводить статические строки, но и динамически встраивать в них данные, чтобы отобразить информацию пользователю в удобном и понятном виде. Это требует использования специальных методов, которые позволяют форматировать строки таким образом, чтобы они могли включать переменные, результаты вычислений и другие динамические элементы.
Эти методы как раз и называются - форматированием строк.
Expression Problem и Объектные алгебры
Expression Problem (EP) — это классическая задача в программировании на совмещение несовместимого.
Автор задачи (Philip Wadler) формулирует следующие цели: создать такую абстракцию, что позволяла бы расширять иерархию в двух направлениях: добавлять новые классы и добавлять новые методы для обработки иерархии, сохраняя при этом строгую статическую типизацию и не требуя изменений существующего кода.
В динамически типизируемых языках мы бы могли добавить или переопределить метод на лету с помощью трюка, ставшего известным под неказистым названием monkey patching (хоть первоначально речь шла совсем не про обезьян, а про партизан — guerrilla).
А вот какие трюки применяют в статически типизированных языках рассмотрим под катом.