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

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

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

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

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

Мне нередко доводилось видеть печальную картину. Человек вроде как умеет работать с Git, знает там всякие git commit и git push, но плохо представляет, что именно с ними нужно делать. На практике это выливается в параллельную работу всей команды над пятью разными бранчами и мержами этих бранчей друг с другом, сорванными сроками потому что «ой, наш билд еще не стабилен», желание смотреть на «карты метро» при помощи IDE или gitk/gitg/tig, уговоры команды взять и дружно заставить себя использовать утилиту gitflow и в прочие ужасные вещи.

Снова и снова я сталкиваюсь с тем, что QA, тестировщики, или как их там у вас называют, не умеют нормально писать багрепорты. Что хуже, они и не хотят учиться делать это правильно. Что намного хуже, часто это касается не только QA и багрепортов, а команды и тикетов вообще в Jira, Trello, или чем вы там пользуетесь.

Пожалуйста, поймите меня правильно. Си я люблю и уважаю. В студенческие годы я провел много увлекательных вечеров за изучением WinAPI и POSIX, написанием своих архиваторов и даже драйверов для Windows XP. Однако так сложилось, что в своей профессиональной деятельности я пишу на более высокоуровневых языках. Вот о том, почему в программах, написанных на таких языках, следует избегать использования Си, мне и хотелось бы поведать.

IntelliJ IDEA — замечательная IDE. Я использую ее для программирования на Scala и Erlang на протяжении, наверное, последних пяти месяцев и теперь просто не представляю, как без нее жить. Однако довольно скоро я обнаружил, что при программировании на Scala в какой-то момент IntelliJ IDEA начинает тупить и выйти из этого состояния ей помогает только перезапуск. В итоге мне ежедневно приходилось один-два раза перезапускать IDE. Не то, чтобы с этим нельзя было жить, но как-то печально, согласитесь. К счастью, решить эту проблему оказалось несложно.

Данная статья кратко представляет вдумчивому читателю планы по проектированию и разработке прототипа Системы поддержки принятия решений при диагностике и лечении судорожного синдрома (СППР ДЛСС). Мы рассмотрим постановку задачи, предназначение Системы, её задачи и очень кратко тот набор методов, которые будут использоваться в работе Системы.

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