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

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

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

В этом выпуске: как программировать под 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 дэдлок в этом случае не произойдет… за исключением одного граничного случая, о котором будет рассказано далее.

Rust — это язык программирования общего назначения от компании Mozilla, разрабатываемый с 2010-го года. Разработчики Rust ставят перед собой задачу с одной стороны достичь производительности C/C++ (все же понимают, DSL’ем для разработки какого браузера является Rust?), а с другой — умудриться сделать язык высокоуровневым и безопасным. К окончанию 2014-го года планируется выпустить бета-версию Rust 1.0. Если все пойдет хорошо, нас ждет релиз Rust 1.0, после чего Mozilla обещает перестать ломать обратную совместимость.

Play Framework — это MVC веб-фреймворк для языков программирования Java и Scala от компании Typesafe. С одной стороны, Play обладает гибкостью и простотой в использовании фреймворков типа Django или Mojolicious, с другой — в нем реализованы многие идеи, например, компилируемость, а следовательно и высокая производительность, строгая статическая типизация и тд, которые мы можем наблюдать, скажем, в Yesod.

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