В прошлой статье мы разобрали теоретические основы реактивной архитектуры. Пришло время поговорить о потоках данных, путях реализации реактивных Erlang/Elixir систем и шаблонах обмена сообщениями в них:
В данной статье речь идёт об Erlang, но всё сказанное в равной степени применимо и к Elixir — функциональному языку, работающему поверх той же виртуальной машины BEAM. Он появился в 2012 году и сейчас активно развивается. Elixir получил более привычный большинству синтаксис плюс обширные возможности метапрограммирования, сохранив преимущества Erlang.
Статья от 2016 года, но речь в ней идёт о базовых концепциях, которые не устаревают.
Ссылки на понятия и комментарии от меня (переводчика) расположены в квадратных скобках [] и снабжены указателем "прим. переводчика".
Если вы найдёте какие-то части перевода недостаточно корректными, особенно в плане терминов, или столкнётесь с любыми другими ошибками — дайте мне, пожалуйста, знать, с удовольствием исправлю.
Отдельное спасибо Яну Гравшину за помощь в вычитке и редактуре текста.
Это свободная расшифровка (или долгий парафраз?) моей презентации на организованной Genetec конференции ConnectDev'16.
Я полагаю, что большинство присутствующих здесь людей никогда не программировало на Эрланге. Возможно, вы слышали о нём, или вам знакомо название. Поэтому моё выступление затронет только высокоуровневые концепции Эрланга, причём таким образом, чтобы оказаться полезным в ваших рабочих или побочных проектах даже если вы никогда не сталкиваетесь с этим языком.
6 марта приглашаем вас на ElixirLangMoscow Meetup #9 в московский офис Mail.ru Group. Язык программирования Elixir продолжает развиваться, и мы вместе с сообществом проводим Elixir-митапы. Программа выступлений адаптирована как под активных разработчиков на Elixir, так и под тех, кто только решается «затащить» язык в проект. Подробности и регистрация — под катом.
Читать полностью »
Волна интереса к микроэлектронным устройствам и их взаимодействию между собой для промышленных и бытовых нужд привела к развитию большого количества конструкторов для разработки на базе достаточно мощных SoC (систем на чипе), достаточно миниатюрных относительно микроконтроллерных решений, но уже содержащих в себе полноценную операционную систему. Разработка приложений для таких конструкторов практически не отличается от обычной серверной разработки, за исключением того, что ограничение по ресурсам все равно надо держать в уме.
Конечно, в идеале лучше вообще Не писать лишнего кода. А если и писать, то, как известно, нужно хорошо продумывать кости системы архитектуру системы и реализовывать мясо системы логику системы. В данной заметке мы приведем рецепты для удобной реализации последнего.
В интернетах довольно много информации и споров по поводу выбора sql/nosql подхода, а также плюсах и минусах того или иного KV-хранилища. То, что вы сейчас читаете, не является пособием по rocksdb или агитацией за использование именного этого хранилища и моего драйвера к нему. Я хотел бы поделиться промежуточным результатом работы по оптимизации процесса разработки NIF для Erlang. В данной статье представлен работоспособный драйвер для rocksdb, разработанный за пару вечеров.
Как известно в кругу Erlang разработчиков: только Erlang разработчики знают как "жить" правильно а все остальные "живут" — неправильно. Не пытаясь оспаривать этот факт, приведем пример Clojure приложения в стиле Erlang, используя библиотеку Otplike.
Как создать веб-сервис, который будет взаимодействовать с пользователями в реальном времени, поддерживая при этом несколько сотен тысяч коннектов одновременно?
Всем привет, меня зовут Андрей Клюев, я разработчик. Недавно я столкнулся с такой задачей – создать интерактивный сервис, где пользователь может получать быстрые бонусы за свои действия. Дело осложнялось тем, что в проекте были довольно высокие требования по нагрузке, а сроки были крайне невелики.
В этой статье я расскажу, как выбирал решение для реализации websocket-сервера под непростые требования проекта, с какими проблемами столкнулся в процессе разработки, а также скажу несколько слов о том, как в достижении вышеуказанных целей может помочь конфигурирование ядра Linux.
В конце статьи приведены полезные ссылки на инструменты разработки, тестирования и мониторинга.
Привет!
2 декабря ждем всех, кто любит делать это функционально на третьей конференции FPConf — конференции о Haskell, Scala, Clojure, Elixir, Kotlin, F# и функциональных подходах в программировании фронтендов, бэкендов и чего угодно на чем угодно. Больше монад, лямбд, замыканий! Всем иммутабельность, друзья :)
Традиционно, приглашаем как опытных функциональщиков, так и тех, кто только хочет получить вдохновение и расширить горизонты.
Цена билета сейчас — 5000 рублей. Регистрация тут.
Что в программе:
Arnaud Spiwack, core-разработчик Coq Proof Assistant, старший архитектор в Tweag I/O
USING HASKELL TO GREAT EFFECT
It is beyond cliché, nowadays, to say that testing is really important. This is even more so in I/O intensive applications because so many things can go wrong. Unfortunately, testing I/O intensive applications is particularly hard. We have to mock all our files, data-bases, and so on. But even so, we're only scratching the surface: so many things can go wrong. How do we test for absence of deadlocks? Of races?
I came to the conclusion that Haskell's insistence on purity made it, paradoxically, one of the best languages to write I/O intensive programs. The reason for this is that Haskell makes it very easy to mock every single aspects of the I/O fabric, hence testing is more powerful. Up to checking for the absence of deadlocks and races. This talk will discuss the programming patterns which emerge from this point of view, and, of course, encourage you do use them in your programs.
