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

Время от времени я заглядываю на Toster.ru и иногда даже отвечаю там на вопросы. Чаще всего люди спрашивают две вещи — как стать программистом и как правильно спроектировать схему базы данных. Мне лично кажется очень странным, что так много людей задают последний вопрос. Мне почему-то всегда казалось, что это такая простая вещь, которую умеют вообще все. Но, раз так много людей интересуются, здесь я постараюсь дать достаточно развернутый и в то же время краткий ответ.

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

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

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

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

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

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

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

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