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

За что мы любим языки с автоматической сборкой мусора? За то, что нам с вами приходится меньше думать. Мы просто создаем новые объекты, а когда они оказываются ненужны, RTS сама освобождает память. Проблема утечки памяти решена, жизнь прекрасна и удивительна! Вот только, к сожалению, это неправда.

Иногда требуется запланировать выполнение кода на определенное время после происшествия какого-то события. Или сказать, что некий код выполняется снова и снова с заданным интервалом времени. Если в вашем проекте используется Akka, то вы можете решать такие задачи просто элементарно… на самом деле нет. Как мы скоро убедимся, даже здесь есть определенные тонкости.

Примем за рабочую теорию, что вы знаете, что такое Disqus. На сайты эта штука, как правило, устанавливается путем размещения небольшого JS-кода. Есть также плагины для различных CMS, но по моему опыту, они тормозные и пользоваться ими нельзя. В итоге складывается нехорошая ситуация — комментарии на сайте есть, а поисковыми системами они индексируются либо очень плохо (Google), либо вообще никак (всеми остальными ПС).

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

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

В этом выпуске: как программировать под Android на Scala и написать свой RabbitMQ на Akka, сервисы, предоставляющие «MongoDB в облаке», как выглядит современный код на С++ и не только. Предыдущие выпуски: сентябрь и октябрь 2014, август 2014, июль 2014, июнь 2014.

Мне нередко доводилось видеть печальную картину. Человек вроде как умеет работать с Git, знает там всякие git commit и git push, но плохо представляет, что именно с ними нужно делать. На практике это выливается в параллельную работу всей команды над пятью разными бранчами и мержами этих бранчей друг с другом, сорванными сроками потому что «ой, наш билд еще не стабилен», желание смотреть на «карты метро» при помощи IDE или gitk/gitg/tig, уговоры команды взять и дружно заставить себя использовать утилиту gitflow и в прочие ужасные вещи.

Помните, как мы учились писать сайтики при помощи Play Framework? Вы, конечно же, обратили внимание, что вопрос работы с какой-либо СУБД был оставлен в стороне. Пришло время исправить эту вопиющую несправедливость!

Проблема с ООП заключается в том, что этим термином сейчас называют все что угодно. Привязал методы к хэшу в Perl — ООП. Наплодил в Erlang процессов, которые обмениваются сообщениями — ООП. Объявил пару-тройку функций для работы с какой-то структурой, и снова ООП. Никто уже толком не понимает, что именно сей термин означает, но все с умным видом его произносят. Стыдно же не знать!

Как нам с вами известно из опыта программирования на Erlang, при работе с акторами иногда могут возникать дэдлоки. Актор А1 шлет запрос с помощью gen_server::call актору А2, тот в свою очередь спрашивает что-то у А1, но А1 ему не отвечает, так как сам еще ждет ответа от А2. Дэдлок, отваливаемся по таймауту. К счастью, когда вы сталкиваетесь с этой проблемой, в логах есть стектрейсы, позволяющие легко диагностировать и исправить ошибку. Так вот, а совсем недавно я узнал, что в Akka дэдлок в этом случае не произойдет… за исключением одного граничного случая, о котором будет рассказано далее.