Чем больше метрик вы пишите, тем лучше. Метрики помогают найти в программе места, нуждающиеся в оптимизации. По метрикам вы можете понять, что именно послужило причиной сбоя в ночь с субботы на воскресенье. Если в очередном билде имеется баг, который не удалось найти в тестовом окружении, вы сразу же узнаете об этом во время выкатки. Одним из наиболее распространенных решений для сбора метрик является Graphite.

Если вкратце, микросервисная архитектура (Micro Service Architecture, MSA), это когда ваше приложение представляет собой много-много небольших (буквально несколько сотен строк кода) сервисов, взаимодействующих между собой путем обмена сообщениями. Это могут быть сообщения Erlang‘а, Cloud Haskell‘я, Akka, или же REST API, Protobuf, MessagePack и так далее. Давайте же попытаемся понять, в каких задачах может быть целесообразно использовать такой подход, чем он хорош, и, конечно же, чем он плох.

В продолжение заметки Я тупой и криворукий джуниор. Еще одна черта моего характера, которой я горжусь, это лень. Казалось бы, всем известно, что лень — это плохо. Как вообще можно ею гордиться? Не волнуйтесь, господа, сейчас я вам все объясню!

На днях кое-кто спросил меня, дескать, на кой черт вообще нужен этот REST. Зачем, например, заморачиваться с методом DELETE или там заголовком Accept? Не проще ли использовать метод GET и передавать все в параметрах, например, delete=true или format=json? Вбил в браузере, и работает! А вот этот ваш DELETE так просто через браузер не пошлешь. На что я ответил примерно так.

Время от времени люди говорят мне, что я что-то делаю не по стандарту, и потому неправ. Дескать, «твоя реализация протокола не соответствует RFC» или «почему ты пишешь void main(), когда по стандарту должно быть int main()»? Меня давно подмывало написать пост на эту тему, и вот, после очередного такого упрека, я собрался с духом.

В последнее время все больше людей выбирают языки программирования с динамической типизацией. Сторонники динамической типизации утверждают, что на изучение Erlang’а требуется две недели, после чего можно разу начать писать боевой код. Что все равно интернеты динамически типизированы, что ошибки типизации быстро находятся и легко устраняются, а настоящую проблему представляют сложные логические ошибки, где статическая типизация все равно не помогла бы. Что статическая типизация — это медленно и скучно, а на Clojure можно легко написать свой Mortal Kombat за два вечера. Давайте же выясним, почему на самом деле вы не должны хотеть динамической типизации.

Сказать по правде, я долгое время не понимал, для чего нужны DSL. В конце концов, всю жизнь без них как-то обходился, и нормально. Какую проблему, спрашивается, они решают? И вообще, у нас тут безо всяких DSL сплошь и рядом зоопарки языков программирования, а вы предлагаете ввести еще один язык!? Но, подумав, поспрашивав людей и погуглив немного, я пришел к выводу, что в ряде случаев создание собственных DSL может быть хорошей идеей. Проще всего убедиться в этом, рассмотрев несколько практических задач и как они решаются с использованием DSL.

Вот многие программисты считают себя умными. Читают Хабр, слушают Радио-Т, рассуждают с умным видом про шаблоны ООП или там теории категорий. И любят делать умные решения. Ведь простые решения любая обезьянка написать может, а вот сложные… Почитывая мой бложик, кто-то из вас мог ошибочно подумать, что я тоже такой весь из себя шибко умный. Знаю там Haskell, книжек много читаю. В действительности, я очень тупой. И поэтому при решении задач стараюсь использовать как можно более тупые решения.

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

Будучи молодым и наивным, я хотел перепробовать на практике все новомодные NoSQL-решения, знать все необычные языки программирования и писать код, покрытый тестами не менее, чем на 98%. Я считал, что при желании смогу одинаково хорошо разбираться как в веб-разработке, так и в написании драйверов для FreeBSD. Теперь, состарившись и помудрев, я начинаю осознавать всю глубину этих, а также других заблуждений. В данной серии заметок я хочу перечислить совершенно очевидные вещи, понимание которых, тем не менее, почему-то приходит только со временем.