Вот многие программисты считают себя умными. Читают Хабр, слушают Радио-Т, рассуждают с умным видом про шаблоны ООП или там теории категорий. И любят делать умные решения. Ведь простые решения любая обезьянка написать может, а вот сложные… Почитывая мой бложик, кто-то из вас мог ошибочно подумать, что я тоже такой весь из себя шибко умный. Знаю там Haskell, книжек много читаю. В действительности, я очень тупой. И поэтому при решении задач стараюсь использовать как можно более тупые решения.
В этой заметке я продолжу делиться удивительными открытиями в отношении разработки программного обеспечения, жизни, ее смысла и вообще. Предыдущую часть вы найдете здесь.
Будучи молодым и наивным, я хотел перепробовать на практике все новомодные NoSQL-решения, знать все необычные языки программирования и писать код, покрытый тестами не менее, чем на 98%. Я считал, что при желании смогу одинаково хорошо разбираться как в веб-разработке, так и в написании драйверов для FreeBSD. Теперь, состарившись и помудрев, я начинаю осознавать всю глубину этих, а также других заблуждений. В данной серии заметок я хочу перечислить совершенно очевидные вещи, понимание которых, тем не менее, почему-то приходит только со временем.
Непрерывная интеграция (continuous integration) — это очень, очень хорошо. Вы настраиваете ее один раз, и ваши волосы моментально становятся гладкими и шелковистыми. В этой заметке будет показано, как просто происходит установка и настройка системы непрерывной интеграции Jenkins.
В этой заметке рассматривается написание автоматических тестов на Erlang. Автотесты помогают находить не только мелкие ошибки, случайно допущенные при внесении изменений в коде, но и серьезные, сложные в обнаружении, ошибки, такие, как состояние гонки. Также тесты полезны по той причине, что чем больше ситуаций и способов использования модуля в них проверяется, тем более продуманные интерфейсы мы пишем.
Программисты постоянно занимаются оптимизацией программ. Это такая же неотъемлемая часть работы, как исправление багов или рефакторинг. Обычно, говоря «оптимизация», мы имеем в виду ускорение программы. Несмотря на то, что под оптимизацией также может пониматься уменьшение объема используемой оперативной памяти или иных ресурсов (скажем, сетевого трафика или заряда батареи), в данной заметке речь пойдет именно об ускорении.
Недавно мне пришло одно интересное письмо. Автор (что характерно, девушка) интересовался, что нужно делать, чтобы стать программистом. С чего начать, какой язык программирования осваивать в первую очередь, и так далее. Мне кажется, это очень занятный вопрос, и сегодня я постараюсь обрисовать свое видение сей проблемы.
В последнее время наблюдается большой интерес к языкам программирования со статической типизацией. Зачастую тот факт, что в неком языке (Scala, Haskell, OCaml, …) используется статическая типизация, преподносится в качестве неоспоримого преимущества этого языка над языками программирования с динамической типизацией (Erlang, Clojure и другие лиспы, Perl, Python, Ruby, …). Здесь имеет место явная подмена понятий, манипуляция неокрепшим сознанием неопытных программистов, троллинг, пропаганда и другие нехорошие вещи.
Как вам хорошо известно, некоторые языки программирования, например, Erlang, поддерживают горячее обновление кода, то есть, обновление кода программы без ее остановки. Часто эта способность преподносится в качестве существенного преимущества языка программирования, который ею обладает, над языками, в которых горячего обновления кода нет. Однако чем больше я думаю о горячем обновлением кода, тем больше склоняюсь к мысли, что на практике оно никому не нужно. И вот почему.
Вот уже более трех лет я пишу код исключительно в vim. Не дано мне понять, что всем так нравится в этих Emacs, Eclipse, IntelliJ IDEA и прочих. Зачем они нужны, если старый добрый vim (который, я полагаю, вам все равно иногда приходится использовать) можно за пять минут превратить в хорошую, годную IDE для любого языка?