Фреймворки бывают разные. Если, например, мы рассмотрим веб-фреймворки, то можно легко заметить их разделение на две большие группы — легковесные фреймворки (например, Scotty, Cowboy, Finagle) и тяжеловесные (Yesod, Play, Catalyst). Первые по сути предлагают собой встраиваемые веб-серверы, возможно, с поддержкой вебсокетов. Во вторых поверх всего этого еще накручена валидация форм, конфиги, i18n, ORM, и так далее. Оборачиваясь назад, я понимаю, что тяжеловесные фреймворки меня всегда чем-то беспокоили, но я не мог четко сформулировать, чем именно. Так было до недавнего времени.
Почему сложно сделать правильное кэширование
13 мая 2015
Вы, наверняка, знаете, как это бывает. Ой, у нас тут такие тяжелые вычисления / так долго тянутся данные из базы. А давайте просто прикрутим кэшик. Что может пойти не так? Так вот, опыт показывает, что пойти не так может очень и очень многое.
Десять веских причин не тащить в продакшн новые игрушки
17 апреля 2015
Типичная ситуация. Программист читает книжку о новом, или не таком уж и новом, языке программирования, базе данных или иной технологии и сгорает от нетерпения поскорее ее попробовать. Возможно, он узнает о технологии или подходе не из книги, а из подкаста или доклада на конференции, не суть важно. Другая похожая ситуация — «в нашем проекте все очень плохо, потому что мы используем DynamoDB (пишем на Java), давайте все перенесем на PostgreSQL (перепишем на Erlang)». В этой заметке я собрал веские причины не поддаваться соблазну протащить новые игрушки в продакшн.
Агрегация логов с помощью сервиса Logentries
8 апреля 2015
Когда вы начинаете использовать auto scaling groups, перед вами встает новая интересная проблема. На серверах, входящих в группу, нужно как-то смотреть логи, но размер и состав группы постоянно меняется. Ходить по SSH и делать tail -f
больше не вариант. Есть много решений проблемы, как SaaS, так и не SaaS. Среди последних следует отметить Syslog, Graylog2 и Logstash. Однако в рамках это заметки речь пойдет об одном из SaaS решений, а именно Logentries.
Велика колхозная доктрина — это квинтэссенция программистской мудрости. Десятилетиями доктрина передавалась членами тайного ордена колхозных программистов из уст в уста, из поколения в поколение. К великому сожалению, со временем учение стало додумываться и обрастать различными толкованиями. Мы видим появление новых те-еретиков, намеренно искажающих доктрину, чтобы поселить сомнения и ужас в наших сердцах. У ордена не осталось иного способа спасти истину, кроме как предать доктрину широкой огласке. Ниже представлена наиболее точное приближение к оригинальной доктрине, которое удалось по крупицам восстановить благодаря небольшой группе посвященных.
Десять причин избегать метапрограммирования
11 февраля 2015
В любой команде рано или поздно появляется человек, который совсем недавно прочитал книжку по Lisp или осилил Template Haskell и потому ему не терпится применить метапрограммирование на практике. Однако проблема заключается в том, что в большинстве случаев макросы или шаблоны создают больше проблем, чем решают. В этой заметке будет показано, почему так.
Чеклист по разработке и поддержке серверсайда
26 декабря 2014
В данной заметке я намерен снова напомнить о том, что программирование — это, оказывается, не только выбор правильного языка и набивание кода. И речь идет не о наличии социальной/психологической составляющей процесса, вовсе нет. Речь все о той же, технической, стороне.
Обратная совместимость и изменение схемы базы данных
5 декабря 2014
Каждый раз одно и то же. Программист что-то там понаписал, его коллега что-то там наревьювил, код вмержен, сторипоинты засчитаны, все здорово, все просто замечательно. Тот факт, что общение с приложением происходит по какому-то протоколу, или что у базы данных есть какая-то схема, почему-то вспоминается в самый последний момент.
Практика работы с системами контроля версий
26 ноября 2014
Мне нередко доводилось видеть печальную картину. Человек вроде как умеет работать с Git, знает там всякие git commit и git push, но плохо представляет, что именно с ними нужно делать. На практике это выливается в параллельную работу всей команды над пятью разными бранчами и мержами этих бранчей друг с другом, сорванными сроками потому что «ой, наш билд еще не стабилен», желание смотреть на «карты метро» при помощи IDE или gitk/gitg/tig, уговоры команды взять и дружно заставить себя использовать утилиту gitflow и в прочие ужасные вещи.
Как не нужно заводить багрепорты и вообще любые тикеты
30 октября 2014
Снова и снова я сталкиваюсь с тем, что QA, тестировщики, или как их там у вас называют, не умеют нормально писать багрепорты. Что хуже, они и не хотят учиться делать это правильно. Что намного хуже, часто это касается не только QA и багрепортов, а команды и тикетов вообще в Jira, Trello, или чем вы там пользуетесь.