Несмотря на существование большого количества распределенных файловых систем (Riak CS, MongoDB GridFS, Cassandra File System, и прочих) многие продолжают отдавать свое предпочтение сервису Amazon S3. Что не удивительно, учитывая его гибкость, разумную стоимость, отсутствие необходимости самому что-либо администрировать и наличие могучего SDK. В этой заметке будет показано, как работать с Amazon S3 при помощи этого SDK на языке программирования Scala.
Как нам с вами уже известно, Akka предоставляет множество богатых средств, существенно упрощающих разработку распределенных приложений. Сегодня мы познакомимся с одним таким средством, а именно — возможностью создавать акторы-одиночки, или синглтоны. Такие акторы присутствуют в кластере в единственном экземпляре. Также в случае падения узла, на котором крутится синглотн, этот синглтон будет перезапущен на другом узле кластера.
В мире JVM уже давно предпринимаются попытки заместить Java чем-то более пристойным. Наиболее успешной такой попыткой, по всей видимости, на сегодняшний день является Scala. Тут вам и сообщество программистов, и куча фреймворков, и вакансии — все что угодно. Но и Scala далека от идеала. Среди наиболее существенных недостатков языка можно отметить его относительную сложность (что признает даже Одерски) и, что намного важнее, медленную скорость компиляции, а также требовательность к ресурсам во время этой компиляции. Поэтому такие языки под JVM, как Kotlin, Gosu и Ceylon все еще представляют собой интерес.
Редкое серьезное приложение в наши дни обходится без кэширования чего-либо. Какой-нибудь LRU кэш элементарно реализуется, например, при помощи хэш-таблиц и двусвязных списков. Но не факт, что ваше решение будет отличаться особой эффективностью, поэтому лучше воспользоваться готовой реализацией. Часто в качестве такой реализации рекомендуют Guava или LruMap из twitter-util. Но у этих решений есть свои минусы, в частности, стэк Twitter’а традиционно привязывает вас к Scala 2.10, а Guava просто страшна.
Как ранее уже отмечалось, Akka позволяет не только создавать акторы, которые обмениваются между собой сообщениями, но и строить кластеры, состоящие из нескольких физических машин. При этом акторы, запущенные на разных машинах, все еще могут взаимодействовать друг с другом. Кроме того, Akka из коробки предоставляет ряд полезных при построении распределенных приложений примитивов. Например, возможность подписаться на события, происходящие с кластером, присваивать узлам роли или запустить актор-одиночку. Что, кстати, делает Akka намного интереснее других реализаций модели акторов (Erlang, Cloud Haskell). В этой заметке мы напишем очень простое приложение, использующее akka-cluster, а также ознакомимся с его поведением при различных условиях.
Рассмотрим такую практическую задачу. Есть некое множество классов. У этих классов есть методы, по которым нам хотелось бы, например, собирать метрики: количество вызовов, время выполнения, число ошибок. Наиболее простой и красивый способ решения этой задачи, не требующий написания тысяч строк кода в разных местах проекта, заключается в использовании динамических прокси-классов.
Сегодня я хотел бы показать один интересный трюк из области квантовых вычислений, который может иметь многочисленные последствия в применении к теории сложности вычислений. Все мы помним про алгоритм Гровера, который даёт хоть и не сверхполиномиальное ускорение для решения задачи неструктурированного поиска, но всё же является более эффективным по сравнению с классическим алгоритмом поиска грубой силы. Собственно, вдумчивый читатель уже должен был всё понять :)
После описания нескольких квантовых алгоритмов, мы можем перейти к рассмотрению ещё одного алгоритма, который наделал больше всего шума, и, собственно, из-за которого, по мнению многих, новая вычислительная модель, основанная на законах квантовой механики, получила такое развитие. Это алгоритм Шора для факторизации целых чисел, являющихся произведением двух простых нечётных чисел.
Когда вы работаете с Akka, и вообще акторами, очень многое может пойти не так. Очереди сообщений могут переполняться, актор может начать перемножать матрички, заняв собой трэд, или, наконец, где-то могут просто начать сыпаться эксепшены. Пока у вас одна нода и мало пользователей, можно, конечно, просто быть на телефоне 24/7 и разбираться в проблемах по логам, отладочным ручкам, ну или remsh, если вы пишите на Erlang. Как только нод становится больше и проект выходит из альфы, такой подход становится совершенно нерабочим. На помощь приходит Kamon.
Нам нередко приходилось сталкиваться с сомнениями касательно перехода на Scala людей, которые в настоящее время пишут на Java. И в самом деле, насколько вообще перспективно переучиваться с простой, понятной и всем известной Java на какую-то там странную и никому неизвестную Scala? Кроме того, ситуацию осложняет тот факт, что поверхностное гугление находит помимо положительных отзывов о Scala и весьма негативные.
