Мой первый подход к IntelliJ IDEA состоялся в середине мая 2014 года. Месяц или полтора я к ней принюхивался, выяснял, есть ли там все нужные мне хоткеи, потому что, работая с Vim, я привык все делать клавиатурой, ну и такого рода вещи. Убедившись, что все в порядке, я стал использовать IDEA в качестве основного редактора кода. Поначалу писал в ней на Erlang и немного на Haskell, а спустя пару месяцев — на Scala. Ну и на Java с Kotlin пописывал немного. Так незаметно пролетел целый год. И сегодня я хотел бы рассказать про все, что удалось выяснить об IntelliJ IDEA за это время — плюсы, минусы, вот это все.

Одна из первых вещей, которой программисты учатся при погружении в мир Java — установка артефактов из Maven Central. Nexus является очень популярным менеджером репозиториев (repository manager) от компании Sonatype. Он позволяет поднимать такой маленький Maven Central внутри вашей компании. В этой заметке будет рассмотрена установка и настройка Nexus, а также хождение в него из SBT. Но сначала мы, конечно же, разберемся, зачем вообще это может быть кому-то нужно.

Не уверен, рассказывал я об этом, или нет, но вот эти любимые некоторыми товарищами строгое доказательство корректности программ/алгоритмов, Agda, зависимые типы и так далее видится мне довольно бесполезной затеей. А также я давно перестал внимать рассуждениям таких же товарищей в стиле «MongoDB плохая база данных, потому что читай Афира, сука» или «Ай-яй-яй, в Cassandra таймстэмпы вместо CRDT, при нетсплите все пойдет вкривь и вкось». Далее я постараюсь объяснить, почему так. А вы, как обычно, прочитаете по диагонали, выдерите слова из контекста и напишет в комментариях, какой я дурак и ничего не понимаю :)

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

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

Типичная ситуация. Программист читает книжку о новом, или не таком уж и новом, языке программирования, базе данных или иной технологии и сгорает от нетерпения поскорее ее попробовать. Возможно, он узнает о технологии или подходе не из книги, а из подкаста или доклада на конференции, не суть важно. Другая похожая ситуация — «в нашем проекте все очень плохо, потому что мы используем DynamoDB (пишем на Java), давайте все перенесем на PostgreSQL (перепишем на Erlang)». В этой заметке я собрал веские причины не поддаваться соблазну протащить новые игрушки в продакшн.

Когда вы начинаете использовать auto scaling groups, перед вами встает новая интересная проблема. На серверах, входящих в группу, нужно как-то смотреть логи, но размер и состав группы постоянно меняется. Ходить по SSH и делать tail -f больше не вариант. Есть много решений проблемы, как SaaS, так и не SaaS. Среди последних следует отметить Syslog, Graylog2 и Logstash. Однако в рамках это заметки речь пойдет об одном из SaaS решений, а именно Logentries.

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

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

В данной заметке я намерен снова напомнить о том, что программирование — это, оказывается, не только выбор правильного языка и набивание кода. И речь идет не о наличии социальной/психологической составляющей процесса, вовсе нет. Речь все о той же, технической, стороне.