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

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

Следующим нашим образовательным проектом станет ScalaDay Spb — первая конференция Scala-разработчиков в Санкт-Петербурге.

1 октября в 16:00 мы ждем всех фанатов Scala в бизнес-инкубаторе «Ингрия». На встрече вы узнаете о реальном опыте применения этого языка и пообщаетесь лично с представителями компаний из Петербурга и других городов, использующих Scala в своих проектах.

• Павел Фатин и Александр Подхалюзин (оба из jetBrains) расскажут о Scala-плагине для IDEA.
• Алексей Злобин (e-Legion) поведает о разработке масштабируемого бэкенда для сервиса Goozy с применением Scala и NoSQL.
• Юрий Буянов (e-Legion) расскажет о некоторых аспектах применения Scala в реальных проектах.
• Эдуард Клементьев (Iamscientist) покажет, как использовать Scala для backend-задач.

Список обновляется. Если вам есть что рассказать — пишите в личку.

Как и всегда, посетить встречу можно совершенно бесплатно, необходимо лишь зарегистрироваться на странице мероприятия.

Typesafe Stack — современная программная платформа, которая обеспечивает возможность создания легко масштабируемых программных систем на Java и Scala. Стек функционирует на JVM, включает в себя фрэймворки Akka 2.0 и Playframework 2.0. Ядром платформы, которое обеспечивает практически неограниченную масштабируемость разрабатываемой системы, является библиотека Akka, реализующая многозадачность на основе модели акторов.

Измерение производительности Play Framework 2.0

Я уже рассказывал о программной платформе Typesafe Stack 2.0. В том посте шла речь об одном из компонентов платформы — фрэймворке Akka 2.0, реализующем модель акторов на JVM. Сегодня я хочу написать о возможностях другой составляющей Typesafe Stack — фрэймворке Play 2.0. Хотя о функциональности данного компонента уже рассказывали здесь и здесь, тема производительности решений под управлением Play 2.0 по-моему осталась не раскрытой.

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

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

Первоначально эту нишу занимали крупные инновационные интернет-компании типа Google или Twitter, однако такие требования к приложениям начали всплывать во многих областях индустрии. Финансовые и телекоммуникационные компании первыми начали внедрять новые практики, чтобы удовлетворить новым требованиям, а теперь подтягиваются и остальные.

Новые требования требуют новых технологий. Предыдущие решения делали упор на управляемые сервера и контейнеры. Масштабирование достигалось засчёт покупки более крутых серверов и использования многопоточности. Для добавления новых серверов приходилось применять комплексные, неэффективные и дорогие проприетарные решения.

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

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

Дорогие коллеги и энтузиасты разработки на Scala!

Скоро заканчивается курс по основам реактивного программирования на coursera.org. Все лекции опубликованы, и задания уже ждут последних сроков.

Курс оставил много впечатлений и вопросов, многие вещи ещё хочется обсудить. Давайте соберёмся, посмотрим вместе последние лекции о scalability, responsiveness и несколько других на выбор, а после обсудим, как лучше всего впустить реактивность в нашу жизнь.

Чай, кофе и печеньки, разумеется, будут.

Для начала количество участников будет довольно ограничено,
пишите мне на почту v.uspenskiy@tcsbank.ru, постараемся все уместиться.

Будем с нетерпением ждать вас в следующий четверг 26 декабря в 20:00, в нашем офисе на водном стадионе.

Кратко рассматривается API библиотеки GPars и решение многопоточной задачи средней сложности, результаты которой могут быть полезны в «народном хозяйстве».

Данная статья написана в ходе исследования различных библиотек акторов, доступных Java-программисту, в процессе подготовки к чтению курса «Multicore programming in Java».

Также я веду курс «Scala for Java Developers» на платформе для онлайн-образования udemy.com (аналог Coursera/EdX).

Это первая статья из цикла статей цель которых сравнить API, быстродействие и реализацию акторов Akka с реализациями в других библиотеках на некоторой модельной задаче. Данная статья предлагает такую задачу и решение на GPars.

GPars — библиотека написанная для Clojure с широкой поддержкой различных подходов к параллельным вычислениям.
Плюсы GPars

• Исходный код написан на Java (в отличии от Akka, написанной на Scala). Всегда интересно посмотреть «что под капотом» на «родном» языке программирования
• GPars представляет собой целый «зоопарк» подходов (Actor, Agent, STM, CSP, Dataflow)
• GPars использует классы из runtime-библиотеки Clojure, написанной на Java. Интересно покопаться

Когда-то давно я уже поднимал тему применения Scala в игровом сервере. Тогда это был совсем простой пример использующий только Scala. С тех времен много воды утекло. Scala и Akka развиваются, но статей по ним что-то не прибавляется. А тема очень интересна. В общем хочется продолжить цикл статей про сервер на Scala. В этой статье будет описана общая архитектура решения. А так же что дает использование Scala и Akka. Примеры кода.

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

Знакомится будем на примере фреймворка akka используя язык java (сам akka написан на scala).

Совсем недавно я перешел с горячо любимого мной объектно-ориентированного C++ на новый для меня и еще не совсем понятный функциональный Scala. Причины перехода — совершенно отдельная история. Но одной из них было наличие достаточно хорошей, судя по отзывам, поддержки модели акторов — с помощью библиотеки Akka. Я давно мечтал опробовать на собственном опыте все описываемые преимущества этой технологии, а существующие реализации на C++ (CAF_C++ и Theron), которые я немного повертел в небольших тестах, оказались достаточно сырыми для моих нужд. Наиболее каноническое же (по моему мнению) решение модели акторов — Erlang, — я отмел, так как посчитал, что для его освоения мне понадобится слишком много времени, да и не факт, что я смогу найти необходимые мне сторонние библиотеки для этого далеко не универсального языка. Поэтому в результате выбор мой пал именно на Scala в связке с Akka, тем более что Scala я когда-то давно уже начинал изучать, но забросил за нецелесообразностью. Однако, как оказалось, на этот раз время для своего эксперимента я выбрал не самое удачное, в чем я убедился только после того, как достаточно солидная часть проекта была уже завершена.

Как я уже писал в своей первой статье, не так давно я перешел c С++ на Scala. И вместе с этим я начал изучать модель акторов в исполнении Akka. Наиболее яркое впечатление на меня произвела лекгость реализации и тестирования конечных автоматов (finite-state machines, FSM), которую предоставляет эта библиотека. Уж не знаю, почему именно так получилось, учитывая изобилие остальных прекрасных и полезных вещей в Akka. Но теперь в моем первом проекте на Scala я использую конечные автоматы при каждой выпадающей возможности, подкрепленной целесообразностью (как я искренне надеюсь). И вот я решил, что готов поделиться с сообществом теми знаниями об Akka.FSM, а также некоторыми хитростями и личными наработками, которые я успел накопить. Подобной темы на хабре я не нашел (да и вообще со статьями про Scala и Akka здесь как-то не густо), и решил, не затягивая, исправить положение и выговориться, пока кто-то не сказал всего раньше меня. А чтобы было не скучно — предлагаю вместе реализовать поведение самого настоящего электронного кота. Хотелось бы верить, что какая-то одинокая романтическая душа, вдохновившись моей статьей, доработает предлагаемый в ней функционал до полноценного «Тамакотчи», в качестве домашнего задания. Главное, чтобы такая душа не забыла после поделиться своими результатами с сообществом в комментариях. В идеальном варианте можно было бы создать проект на гитхабе с общим доступом, чтобы каждый желающий смог привнести свой личный вклад в развитие идей трансгуманизма. А теперь — в сторону шутки и фантазии, закатываем рукава. Начинать мы будем с самого нуля, а я для пущего 7D и эффекта присутствия я буду проделывать каждый шаг вместе с вами. TDD прилагается: с неоттестированным робокотом уж точно будет не до шуток.

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

Добро пожаловать в Akka.NET Bootcamp. Это бесплатный курс для самостоятельного обучения, подготовленный парнями из Petabridge.

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

Мы начнем с некоторых основных акторов и постепенно будем подходить к большим и более сложным примерам.

Этот курс для самостоятельного обучения — вы можете выполнять его в любом темпе на ваше усмотрение. Вы можете подписаться здесь и каждый день получать по одному уроку Akka.NET на ваш email (на английском языке — от перев.) если хотите.

ПРИМЕЧАНИЕ: На текущий момент учебный курс рассчитан на использование C# в качестве языка программирования.
Мы намерены добавить поддержку F# в будущем
(Также мы принимаем F# pull-реквесты)

Что вы узнаете

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

Привет, меня зовут Макс Матюхин, я PHP-программист в компании Badoo. В прошлом месяце в Лондоне прошла очередная Международная конференция разработчиков QCon 2015. Я побывал на ней и теперь хочу поделиться с вами своими впечатлениями о мероприятии и рассказать о самых интересных, на мой взгляд, выступлениях. Из этой статьи вы узнаете чуть больше про архитектуру Uber, Spotify, CloudFlare, а также о том, как Google управляет своей инфраструктурой и многом другом.

Впервые QCon состоялась в 2007 году в Лондоне и Сан-Франциско. С тех пор она стабильно набирает популярность и расширяет географию, и в этом году она пройдет в 8 городах. Лондонская QCon проходит в самом сердце британской столицы, в двух шагах от Вестминстерского Аббатства. В разное время на QCon выступали такие известные личности, как Martin Fowler, Kent Beck, Erik Meijer, Steve Vinoski, Joe Armstrong, Rich Hickey и многие другие.

В последнее время мы часто слышим о реактивном программировании и видим различные баззворды: message-driven архитектура, event-sourcing, CQRS. К сожалению, на Хабре об этом пишут довольно мало, поэтому я решил исправить ситуацию и поделиться своими знаниями со всеми желающими.

В этой статье мы узнаем об основных особенностях реактивных приложений, рассмотрим, как паттерны CQRS и EventSourcing помогут нам в их создании, а чтобы не было скучно, мы с вами шаг за шагом сделаем свой мессенджер с вебсокетом и акторами, соответствующий всем канонам реактивного программирования. Для реализации всего этого добра, мы будем использовать замечательный язык Scala вместе с не менее превосходной библиотекой Akkа, реализующей модель акторов. Еще, мы будем использовать Play Framework для написания веб-составляющей нашего приложения. Итак, приступим.

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

В прошлый раз я описал в общих чертах использование Akka для игрового сервера.
Сейчас разберем простой, но тем не менее рабочий пример сервера.

Привет, Хабр! Все привыкли ассоциировать обработку больших данных с Hadoop (или Spark), которые реализуют парадигму MapReduce (или его расширения). В этой статье я расскажу о недостатках MapReduce, о том, почему мы приняли решение отказываться от MapReduce, и как мы приспособили Akka + Akka Cluster на замену MapReduce.

Здравствуйте, уважаемые читатели.

Сегодня мы хотели поговорить с вами на тему «все новое — это хорошо забытое старое» и вспомнить об акторах, описанных Карлом Хьюиттом еще в начале 70-х. А все дело в том, что недавно вышла вот такая книга:



Она довольно объемная — в переводе должна получиться более 500 страниц.

Несмотря на подчеркнутую элитарность книги (Akka и Scala), ее автор Вон Вернон (крупнейший специалист по DDD) уверен, что архитектурные паттерны, описанные в этой работе, вполне реализуемы на .NET и C#, о чем рассказывает в приложении. Мы же размещаем под катом перевод статьи, автор которой допускает перенос акторной парадигмы на язык Java. Поскольку рейтинг книги на Amazon стабильно высок, а тема универсальна, просим поделиться вашими мнениями как о ней, так и об акторной архитектуре в принципе.

Представляю вашему вниманию перевод статьи Tailing the MongoDB Replica Set Oplog with Scala and Akka Streams.

Введение

В этой статье я попробую объяснить, как следить за обновлениями в MongoDB Oplog при помощи Scala драйвера MongoDB и Akka Streams.
Примеры, приведенные в данной статье не следует рассматривать и использовать в продакшн среде.
Каждый из нас знает Unix команду tail -f, Tailable Cursor имеет тот же концепт. MongoDB предоставляет возможность использовать эту функцию по умолчанию и не требует дополнительных библиотек и инструментов. Что касается Oplog — это такая же коллекция, как и все остальные и ничего нового не требуется.
Если вы хотите узнать больше об Oplog и Tailable Cursor, то вы можете найти больше информации в документации MongoDB:

• Replica Set Oplog
• Create Tailable Cursor

Проект созданный в данной статье удобно расположился на Github.

Меня зовут Дима и я разработчик. Живу в Минске, люблю посещать зарубежные конференции. Ну вот устал однажды ездить и решил сходить локально. Но выбора было мало. Поэтому вдвоём со своим верным товарищем решили сделать конференцию самостоятельно. Назвали JET. Потому что начинается с J, как и Java, а ещё можно сделать слоган "Let's fly to Java world". Ну что же, как это было?

Открытие

Началось все с выступления организаторов, где мы поделились тем, как зарождалась идея конференции. Рассказали о том, как мы прошли путь в 4 месяца подготовки, и что по итогу получилось. А получилось — 3 потока концентрированных знаний, 300 участников и первый кирпичик в фундаменте дома конференции JET.