Как вы можете помнить, в мире Java есть такая штука под названием type erasure. Мы сталкивались с ней, когда в первый раз пробовали работать с JSON в Scala. Суть проблемы заключается в том, что во время выполнения программы нельзя узнать точный тип генериков, так как информация о типах, которыми они были параметризованы, теряется на этапе компиляции. Вызвано это в основном историческими причинами, так как генерики появились только в Java 1.5, но в какой-то степени, наверное, это также можно считать и оптимизацией. К счастью, в Scala это ограничение можно легко обойти, воспользовавшись TypeTags.
Во многих серверных приложениях часто возникает необходимость кэшировать какие-то данные, так как количество тактов процессора ограничено, хождение в базу по сети занимает ощутимое время, да и пулы коннектов не резиновые. Сделали кэши, все хорошо. Но как только ваше приложение начинает работать более, чем на одном сервере, возникает проблема инвалидации кэшей. Когда пользователь пишет какие-то данные через один сервер, требуется обновлять или сбрасывать кэши на всех остальных серверах. Отчасти проблему позволяет решить Memcached, но с ним другие проблемы — (1) неизбежные накладные расходы на хождение по сети и (2) не всегда понятно, как сделать так, чтобы данные в кэше не разъехались в граничных случаях типа нетсплитов и поднятия новых кэш-серверов. Оказывается, что Akka Cluster из коробки предлагает довольно интересное решение озвученных проблем.
ElastiCache — один из множества сервисов в Amazon, который дает облачные Memcached и Redis. Дает не просто так, а с автоматической заменой упавших нод, а также со специальным клиентом, который определяет состав созданного кластера и ходит на различные его узлы в зависимости от значения ключа. То есть, получается что-то вроде EC2 инстансов с поднятым Memcached или Redis на них в автоскейлинг группе за ELB, только с шардированием и уже готовое. В этой заметке мы научимся настраивать Amazon ElastiCache и ходить в него из кода на языке Scala.
Мне давно было интересно попробовать пописать под Android. Достоверно известно, что Scala без труда справляется с этой задачей, но вот что именно как настраивать было не очень понятно. А тут недавно добрыми людьми был опубликован шаблон готового Android-приложения на Scala. Все сделано за нас, остается только разобраться с настройкой среды разработки, и можно писать для мобилок! Вот о том, как эту среду разработки настроить, я и поведаю далее.
В прошлый раз мы научились работать с WAV-файлами. Точнее, мы с вами научились работать с заголовком, а сами данные за нас проиграл кто-то другой. Настало время поработать непосредственно с самими данными, а заодно и попрактиковаться в работе с двухмерной графикой при помощи Java 2D.
В этой заметке будет описана структура WAV-файла, где у него заголовок, где данные, и что они из себя вообще представляют. Кроме того, мы узнаем, как можно воспроизвести WAV-файл на Scala, притом данные для воспроизведения могут браться не только из файлов на диске, но и передаваться по сети или даже генерироваться программой на лету. Но сначала вспомним немного теории.
Все мы любим JSON. Это простой формат, хорошо читаемый, удобный при отладке, стандарт де-факто во всяких там REST-ах, и не только. Более того, JSON может быть еще и довольно компактным, например, если передавать список с именами полей один раз, а за ним — списки значений. Или если просто сжать его при помощи gzip. В мире Scala есть немало библиотек для работы с JSON, но наиболее мощной и производительной, видимо, является json4s.
Несмотря на существование большого количества распределенных файловых систем (Riak CS, MongoDB GridFS, Cassandra File System, и прочих) многие продолжают отдавать свое предпочтение сервису Amazon S3. Что не удивительно, учитывая его гибкость, разумную стоимость, отсутствие необходимости самому что-либо администрировать и наличие могучего SDK. В этой заметке будет показано, как работать с Amazon S3 при помощи этого SDK на языке программирования Scala.
Как нам с вами уже известно, Akka предоставляет множество богатых средств, существенно упрощающих разработку распределенных приложений. Сегодня мы познакомимся с одним таким средством, а именно — возможностью создавать акторы-одиночки, или синглтоны. Такие акторы присутствуют в кластере в единственном экземпляре. Также в случае падения узла, на котором крутится синглотн, этот синглтон будет перезапущен на другом узле кластера.
Редкое серьезное приложение в наши дни обходится без кэширования чего-либо. Какой-нибудь LRU кэш элементарно реализуется, например, при помощи хэш-таблиц и двусвязных списков. Но не факт, что ваше решение будет отличаться особой эффективностью, поэтому лучше воспользоваться готовой реализацией. Часто в качестве такой реализации рекомендуют Guava или LruMap из twitter-util. Но у этих решений есть свои минусы, в частности, стэк Twitter’а традиционно привязывает вас к Scala 2.10, а Guava просто страшна.