Рубрика «событийное программирование»

в 8:48, , рубрики: async/await, asyncio, Elixir, erlang, Erlang/OTP, python, twisted, Блог компании Конференции Олега Бунина (Онтико), Программирование, Разработка веб-сайтов, событийное программирование

В книге «Python. К вершинам мастерства» Лучано Рамальо описывает одну историю. В 2000 году Лучано проходил курсы, и однажды в аудиторию заглянул Гвидо ван Россум. Раз подвернулся такой случай, все стали задавать ему вопросы. На вопрос о том, какие функции Python заимствовал из других языков, Гвидо ответил: «Все, что есть хорошего в Python, украдено из других языков».

Это действительно так. Python давно живет в контексте других языков программирования и впитывает концепции из окружения: asyncio позаимствован, благодаря Lisp появились лямбда-выражения, а Tornado скопировали с libevent. Но если у кого и стоит заимствовать идеи, так это у Erlang. Он создан 30 лет назад, и все концепции в Python, которые сейчас реализуются или только намечаются, в Erlang давно работают: многоядерность, сообщения как основа коммуникации, вызовы методов и интроспекция внутри живой системы на продакшн. Эти идеи в том или в ином виде находят своё проявление в системах вроде Seastar.io.

Elixir как цель развития для python async - 1

Если не брать во внимание Data Science, в котором Python сейчас вне конкуренции, то все остальное уже реализовано в Erlang: работа с сетью, обработка HTTP и веб-сокетов, работа с базами данных. Поэтому Python-разработчикам важно понимать, куда будет двигаться язык: по дороге, которую уже прошли 30 лет назад.

Чтобы разобраться в истории развития других языков и понять, куда двигается прогресс, мы пригласили на Moscow Python Conf++ Максима Лапшина (erlyvideo) — автора проекта Erlyvideo.ru.

Под катом текстовая версия этого доклада, а именно: в каком направлении вынуждена развиваться система, которая продолжает мигрировать от простого линейного кода к libevent и дальше, что общего и в чем отличия между Elixir и Python. Отдельное внимание уделим тому, как на разных языках программирования и платформах управлять сокетами, потоками исполнения и данными.
Читать полностью »

в 12:37, , рубрики: mail.ru, tarantool, tarantool-queue, Алгоритмы, Анализ и проектирование систем, Блог компании Mail.Ru Group, высокая производительность, Разработка веб-сайтов, событийное программирование

Tarantool: когда на сервис оповещения миллиона пользователей нужно 500 строк кода - 1

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

На написание данной статьи меня натолкнула эта статья.

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

Читать полностью »

в 6:43, , рубрики: .net, C#, c#.net, wcf, Блог компании Тинькофф Банк, ненормальное программирование, Программирование, распределенные системы, событийное программирование
[The Methanum project] Создание инструментария для построения распределенных систем с топологией “Звезда” - 1

Звезда — на сегодняшний день самая распространенная топология компьютерных сетей. Такая структура обладает рядом преимуществ: легкостью масштабирования, надежностью (выход из строя одной машины не сказывается на других) и простота администрирования. Конечно это решение из физического уровня давно реализовано и на программном уровне. Тем не менее, представляю на суд читателей свою версию инструментария .Net для построения распределенных систем с топологией звезда. Читать полностью »

в 11:23, , рубрики: coroutine, event loop, event-driven programming, python, tornado, yield from, Алгоритмы, параллельное программирование, паттерны проектирования, событийное программирование

Статья про то, как с помощью расширенных генераторов Python сделать собственную реализацию сопрограмм, переключающихся по получению событий. Простота кода получившегося модуля вас приятно удивит и прояснит новые и мало используемые возможности языка, которые можно получить, используя такие генераторы. Статья поможет разобраться и с тем, как это устроено в серьезных реализациях: asyncio, tornado, etc.
Читать полностью »

в 20:40, , рубрики: event-driven, java, Программирование, событийное программирование, теги никто не читает, метки: , , ,

Немного лирики

image
Чем дольше я программирую, тем больше мне нравятся слабосвязанные системы, которые состоят из большого числа разрозненных единиц (модулей), ничего не знающих друг о друге, но предполагающих существование других. Такие системы в идеале должны собираться подобно конструктору, без зависимостей и без адаптирования друг к другу. В идеале, в процессе работы такой системы, все необходимые задачи должны выполняться без остановки системы, простым введением нового модуля в мир (скажем, вбросом jar'ника в classpath), и система немедленно начнет взаимодействовать с новым модулем.
В связи с этим, очень привлекательно выглядит парадигма event-driven (или Событийно-ориентированное) программирование.
Читать полностью »

в 15:35, , рубрики: javascript, JS, StateController, Веб-разработка, событийная модель, событийное программирование, фреймворк, метки: , , ,

StateController. Событийная модель в разработке интерфейсов. Часть 2
Часть 1

В данной статье мы рассмотрим базовые понятия событийной модели StateController'а.

Зоны распространения событий

В селективной модели приложений работа ведется с теми элементами, которые были предварительно выбраны для работы. В чистой событийной модели событие должно распространяться на все элементы DOM-дерева. Это совершенно не важно на маленьких объемах, но при росте количества нод деградация скорости будет даже не линейной. Представьте себе, что событие click должно пройтись по всем нодам, чтобы определить, на каких именно элементах оно сработает. Есть предположение, что псевдокласс :hover в IE6 именно так и работал, поэтому он так сильно тормозил.

Чтобы хоть как-то ускорить работу генератора событий, не заставляя его постоянно обходить все дерево нод, лучшим решением является ограничение зон распространения событий. Фактически, мы используем селективную модель внутри событийной, но с некоторыми ограничениями.
Читать полностью »

в 11:57, , рубрики: javascript, JS, StateController, Веб-разработка, событийная модель, событийное программирование, фреймфорк, метки: , , ,

StateController. Событийная модель в разработке интерфейсов. Часть 1

Введение

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

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

в 11:37, , рубрики: agile, Core, Events, ненормальное программирование, ооп, Программирование, событийное программирование, метки: , , ,

Я работаю программистом более 5 лет (web), и хотел бы поделиться методикой, которая экономит силы, время и помогает автоматизировать процесс проектирования.

Методика основана на объектно-ориентированном проектировании, но несколько необычна. Зато имеет очевидные плюсы:
— в идеале, программирование по CORE сводится к описанию задачи (код близок к бизнес-логике)
— чётко разделяет систему на слабосвязанные компоненты
— легко автоматизируема, позволяет генерировать осмысленный код

Почему методика называется CORE и как это расшифровывается? Отчасти потому, что у меня тяга к красивым названиям. По буквам:
Context — контекст вычислений (что инициировало вычисления)
Object — объект, который производит вычисления
Request — действие, которое нужно совершить, чтобы объект смог продолжить вычисления
Event — событие, которое происходит с объектом

Плюсы по сравнению со стандартными способами разработки:
— ускорение стадии проектирования за счёт формализованной схемы проектирования
— ускорение стадии разработки за счёт умной генерации кода
— автоматизация создания юнит-тестов
— неглючная реализация бизнес-логики практически любой сложности
— простая поддержка кода
— простота совместного владения кодом

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

Читать полностью »

Главная   |  Архив новостей  |   Android  |   Google  |   Apple  |   Microsoft  |   Информационная безопасность  |   Веб – разработка
Публикации RSS  |  Комментарии RSS
https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js