Записки программиста

Фреймворки бывают разные. Если, например, мы рассмотрим веб-фреймворки, то можно легко заметить их разделение на две большие группы — легковесные фреймворки (например, Scotty, Cowboy, Finagle) и тяжеловесные (Yesod, Play, Catalyst). Первые по сути предлагают собой встраиваемые веб-серверы, возможно, с поддержкой вебсокетов. Во вторых поверх всего этого еще накручена валидация форм, конфиги, i18n, ORM, и так далее. Оборачиваясь назад, я понимаю, что тяжеловесные фреймворки меня всегда чем-то беспокоили, но я не мог четко сформулировать, чем именно. Так было до недавнего времени.

Ранее мы уже выясняли, что C++ никогда не умрет, и знать низкоуровневые вещи приходится, даже если фултайм пишешь на Scala. Поэтому я решил уделять некоторое время пописыванию небольших программок на C/C++. Тем более, что с тех пор, когда я активно этим делом увлекался, прошло уже лет семь-восемь и многое сильно изменилось. Так, например, в стандартной библиотеке C++ появились регулярные выражения, пример работы с которыми и приводится в этом посте.

Успешно ассимилировал очередную пачку литературы. В этот раз мой выбор пал на подозрительно большое количество книг о всяких там Cassandra, Kafka и прочих Couchbase’ах, а также парочку книг о современном С++. Другие мои рецензии на прочитанные книги вы найдете здесь: десятый десяток, девятый десяток, восьмой десяток, седьмой десяток.

Согласно официальному описанию, Finagle — это расширяемая RPC система для JVM, используемая для построения «сильно многопоточных» (high-concurrent, что бы это ни значило) сервисов. Finagle изначально был создан ребятами из Twitter, но сейчас успешно применяется и в Foursquare, Pinterest, SoundCloud, Tumblr, а также ряде других компаний. В этой заметке мы познакомимся с основами использования Finagle, создав с его помощью очень простой REST-сервис.

Вы, наверняка, знаете, как это бывает. Ой, у нас тут такие тяжелые вычисления / так долго тянутся данные из базы. А давайте просто прикрутим кэшик. Что может пойти не так? Так вот, опыт показывает, что пойти не так может очень и очень многое.

Пожалуй, основной областью применения Go на сегодня является написание серверных приложений. А их трудно представить в отрыве от какой-нибудь базы данных. В этой заметке я опишу создание простой телефонной книги с интерфейсом командной строки и PostgeSQL в качестве хранилища.

Клиенты нередко приходят в наш сервер сайд или вебчик через какие-то прокси, Nginx, HAProxy, Elastic Load Balancer и другие. Прокси эти очень полезны, так как обеспечивают сжатие и шифрование трафика, балансировку нагрузки и так далее. Проблема однако заключается в том, что прокси скрывают настоящий IP пользователя, из-за чего становится невозможно определить, например, из какой страны он пришел, и соответственно, интерфейс на каком языке ему отобразить. В случае с HTTP эта проблема давно решена путем проставления заголовков с IP пользователя. Но что делать при использовании других протоколов, вебсокетов там или просто чего-то самописного поверх TCP? Вот для решения именно этой проблемы разработчиками HAProxy и был придуман proxy protocol.

В этом выпуске: находим неиспользуемые jar’ники и прикручиваем таймауты к футурам, находим правильную IDE для Haskell, выбираем SaaS для агрегации логов, замораживаем Docker-контейнеры, а также другие интересные ссылки. Предыдущие выпуски: март 2015, февраль 2015, январь 2015, декабрь 2014.

Как вы можете помнить, в мире Java есть такая штука под названием type erasure. Мы сталкивались с ней, когда в первый раз пробовали работать с JSON в Scala. Суть проблемы заключается в том, что во время выполнения программы нельзя узнать точный тип генериков, так как информация о типах, которыми они были параметризованы, теряется на этапе компиляции. Вызвано это в основном историческими причинами, так как генерики появились только в Java 1.5, но в какой-то степени, наверное, это также можно считать и оптимизацией. К счастью, в Scala это ограничение можно легко обойти, воспользовавшись TypeTags.

Во многих серверных приложениях часто возникает необходимость кэшировать какие-то данные, так как количество тактов процессора ограничено, хождение в базу по сети занимает ощутимое время, да и пулы коннектов не резиновые. Сделали кэши, все хорошо. Но как только ваше приложение начинает работать более, чем на одном сервере, возникает проблема инвалидации кэшей. Когда пользователь пишет какие-то данные через один сервер, требуется обновлять или сбрасывать кэши на всех остальных серверах. Отчасти проблему позволяет решить Memcached, но с ним другие проблемы — (1) неизбежные накладные расходы на хождение по сети и (2) не всегда понятно, как сделать так, чтобы данные в кэше не разъехались в граничных случаях типа нетсплитов и поднятия новых кэш-серверов. Оказывается, что Akka Cluster из коробки предлагает довольно интересное решение озвученных проблем.