#python — посты и обсуждения

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

1. Введение

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

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

Поскольку микрофреймворки сосредоточены только на основах, без лишних функций, их проще изучать и использовать, чем более комплексные фреймворки, такие как Ruby on Rails или Django. Это означает, что разработчикам не нужно тратить время на изучение множества ненужных функций, чтобы быстро начать работу над своим проектом. Кроме того, меньшее количество встроенных библиотек упрощает разработчикам и специалистам по безопасности отслеживание известных уязвимостей в коде.

Хотя микрофреймворки не подходят для крупномасштабных проектов, как это было бы в случае с полнофункциональными фреймворками, главным образом потому, что их набор функций может быть недостаточным в определенных условиях, они обеспечивают мощную совместимость с различными языками программирования, предоставляя разработчикам большую гибкость при создании API или быстром прототипировании нового проекта с нуля. К популярным примерам микрофреймворков относятся Flask (Python), Express (Nodejs), Sinatra (Ruby) и Laravel Lumen (PHP).

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

2. Функции, предоставляемые микрофреймворками.

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

- Промежуточное ПО (middleware): Промежуточное ПО — это метод обработки запросов пользователей, предоставления дополнительных функций, таких как аутентификация, заголовки и фильтры. Микрофреймворки обладают мощными возможностями промежуточного ПО. Это позволяет разработчикам легко создавать сложные приложения с минимальными усилиями.

- Безопасность: Микрофреймворки изначально разрабатывались с учетом требований безопасности. Они предлагают инструменты для защиты ваших приложений от вредоносных атак, таких как SQL-инъекции и атаки межсайтового скриптинга (XSS), и многих других. Кроме того, многие микрофреймворки имеют встроенную защиту от распространенных уязвимостей веб-приложений, таких как межсайтовая подделка запросов (CSRF).

- Интеграция с базами данных: Главная особенность большинства микрофреймворков — это их способность интегрироваться с базами данных, такими как MySQL или MongoDB, для эффективного и безопасного хранения данных. Кроме того, многие из них позволяют разработчикам запрашивать данные из базы данных с помощью объектно-реляционных сопоставителей (ORM). Это значительно сокращает время разработки, поскольку исключает необходимость написания SQL-запросов вручную...

#DST #DSTGlobal #ДСТ #ДСТГлобал #DSTplatform #ДСТПлатформ #микрофреймворк #микрофреймворки #Flask #Python #Express #Nodejs #Sinatra #Ruby #Laravel #Lumen #PHP #CSRF #XSS #фреймворки #frameworks #API #HTML5 #CSS #AJAX #CMS #ecommerce #HIPAA #middleware #PHPStan #GraphQL #serverless #микросервисы #MySQL #MongoDB

Источник: https://dstglobal.ru/club/1259-rukovodstvo-po-mikrofreimvorkam

Раннее писал о том, как наконец запустил обучение нейронных сетей в связке Metatrader+dll+R+Python+(Deepnet, Keras, Tensorflow и др).

https://finbazar.ru/post/186859-suslik-est-ili-net-sravnenie-rsi-random-i-ii-ml-dl-dnn-lstm-v-trejdinge

Раз все теперь работает корректно, можно продолжить эксперименты.

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

Настало время немного “подкрутить” параметры. Для иллюстрации, того, как изменится кривая Equity изменим параметры учителя немного, а именно сделаем два канала и синхронизируем их. Все, что не удалось синхронизировать в одинаковую сторону сигналы двух каналов, обозначим, как NA и в последствии уберём из обучающей выборки.

Период, принципы торговой системы (ТС) из предыдущей статьи и другие параметры сетей изменять не будем (пример №1 из предыдущей статьи).

Был запущен дополнительный вариант тестирования, при котором позиция закрывалась на следующем баре, если не достигла заданного TP. Посмотрим, что получилось.

Именно такое название хотелось обозначить и закрыть свой “гештальт” в вопросе целесообразности (эффективности) использования каких либо “индюков” (индикаторы) или ML/DL при предсказании (найти в хаосе тренд) будущей цены на валютных парах.

Наверное, много, кто “гонял” оптимизатор и история, чтобы найти оптимальные параметры на какой-то срок, потом круг повторялся, когда все ломалось. Мне надоело, так делать и мне хотелось, чтобы механизм нейронных сетей (ML/DL) делал это за меня и за тестер. Так, начал свой “ресерч” (мне было очень интересно сравнить разные сигналы в одинаковых условиях ТС), потом забрасывал на годы, потом пересматривал и вот наконец, все таки, “добил” и оно “заработало”.

Предлагаю выбрать (LSTM, DNN_v1, RSI, DNN_v2, Random) и написать свой ответ в комментариях, какому варианту результата соответствует данный график Equity:

Аннотация. Объектно-ориентированное программирование (ООП) предоставляет мощные механизмы для структурирования кода, но не фиксирует смысл предметной области. Изменения в иерархиях классов, рефакторинг и эволюция бизнес-правил приводят к семантическому дрейфу — расхождению между тем, что код делает, и тем, что он должен означать. В статье рассматривается подход, реализованный в экосистеме Λ-Универсум: LOGOS-κ как исполняемый онтологический язык и SemanticDB как живая онтологическая память.

Эти инструменты не заменяют ООП, а дополняют его формальным слоем, обеспечивающим верификацию бизнес-инвариантов, аудит изменений и интероперабельность на уровне смыслов. Приводится практический пример интеграции с Python-проектом.

1. Введение: границы объектно-ориентированного моделирования

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

На практике это приводит к следующим проблемам:

- Семантический дрейф — со временем код перестаёт соответствовать исходному замыслу, потому что изменения не сопровождаются фиксацией изменения смысла.

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

- Трудности аудита — невозможно восстановить, почему было принято то или иное архитектурное решение.

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

Экосистема Λ-Универсум предлагает решение, которое не отвергает ООП, а надстраивает над ним формальный онтологический слой. Этот слой представлен двумя ключевыми инструментами: языком LOGOS-κ и базой данных SemanticDB.

2. LOGOS-κ: исполняемая онтология для ООП-систем

LOGOS-κ — это предметно-ориентированный язык и протокол обмена смыслами, реализующий шесть онтологических операторов. В контексте ООП эти операторы получают конкретную инженерную интерпретацию.

2.1. Отображение операторов на задачи ООП

| Оператор | Онтологическая функция | Отображение на ООП |

|----------|------------------------|-------------------|

| Α (Alpha) | Фиксация сущности — коллапс потенции в акт | Сопоставление класса или интерфейса с онтологическим узлом, содержащим его бизнес-смысл, атрибуты и ограничения. |

| Λ (Lambda) | Установление связи как активного агента | Описание отношений между классами (наследование, композиция, зависимость) с указанием семантического типа связи, уверенности (`certainty`) и истории. |

| Σ (Sigma) | Синтез нового целого из существующих частей | Создание нового онтологического узла, соответствующего паттернам композиции (например, Decorator, Strategy) с формальной проверкой согласованности инвариантов. |

| Ω (Omega) | Диагностика — извлечение инварианта | Анализ графа зависимостей на конфликты, циклы, нарушения бизнес-правил. Результат — отчёт о «напряжениях» и предложения по корректировке. |

| ∇ (Nabla) | Обогащение — интеграция извлечённого урока | Применение результатов диагностики: обновление весов связей, маркировка проблемных узлов, генерация задач для разработчиков. |

| Φ (Phi) | Диалог с ИИ с оценкой генеративности (NIGC) | Структурированный вызов LLM для предложения рефакторинга или генерации кода, с автоматической валидацией предложения на соответствие онтологическим контрактам. |

2.2. Отличие от UML и других моделей

В отличие от статических диаграмм UML, LOGOS-κ обеспечивает исполняемость...

#Семантическаяцелостность #ООП #онтологическийслой #LOGOSκ #SemanticDB #ΛУниверсум #NIGC #онтология #HabeasWeights #FAIRCARE #DbC #Java #UML #GDPR #FDA #LinkedData #JSON #Turtle #OpenAPI #GraphQL #GraphML #Python #искусственныйинтеллект

Источник: https://dstglobal.ru/club/1251-semanticheskaja-celostnost-v-oop-sistemah-ontologicheskii-sloi-logos-i-semanticdb.html

Что такое облачные вычисления? 🏢

Представьте, что вместо того чтобы запускать скрипт на своем домашнем ноутбуке, вы арендуете крошечный, но очень мощный системный блок у IT-гиганта (Яндекса, VK или Amazon). Этот виртуальный сервер стоит в дата-центре:

У него идеальные условия (охлаждение, питание).

Он подключен к интернету оптикой.

Он работает 24/7 без праздников и обновлений Windows.

Облако — это просто аренда мощностей чужого компьютера через интернет.