Clojure *

Мне нравится экспериментировать с разными парадигмами и играться с разными интересными (для меня) идеями (некоторые из них превращаются в посты: раз, два). Недавно я решил проверить, смогу ли я писать объектно-ориентированный код на функциональном языке.

Неделю назад в издательстве "Ридеро" вышла книга "Clojure на производстве". Как ее автор, расскажу о ней подробнее: что внутри и кому она полезна.

Общие сведения

Это книга о том, как применять Clojure в настоящих условиях: не сортировать списки в олимпиадных задачах, а поднимать веб-приложения, строить системы, писать тесты. Мой опыт с Clojure показывает, что переход от теории к практике происходит болезненно. Руководства обещают чистоту и неизменяемость, но на практике нам дают код, полный побочных эффектов и состояния.

Это книга — попытка облегчить погружение в практику. Одновременно хочу развеять ложные надежды: Clojure — прекрасный язык, но и в нем не бывает чудес.

От других материалов по Clojure книга отличается следующим. Прежде всего, это не перевод. Я не зря делаю на этом акцент во вступлении. Проблема переводов в том, что в издательствах не понимают технические термины и пытаются их адаптировать. Token становится маркером, trait — чертой, persistence — сохранностью. Формально перевод корректный, но пропадает живость описания, и к нему падает интерес. В своей книге я не срезал углы: если у слова нет однозначного перевода, я ставил английский вариант — тот, в котором мы видим его каждый день.

Привет! Меня зовут Рома, я работаю iOS-разработчиком в Exness. А кроме того, пишу на Clojure и инвестирую.

Сегодня я расскажу о том, как оценивать опционы. Это вводная статья и заработать миллион, используя предложенный способ, вряд ли получится. Тем не менее, это хорошая основа для понимания более сложных методов оценки.

Я написал книгу, предварительный релиз, о создании веб-приложений с нуля.

Я прочитал много книг по программированию, но, часто, после прочтения у меня оставался только один вопрос — Как мне применить эти знания на практике?

Предположим, вы разработчик системы автоматизации, портала или интернет-магазина.
Добавление новой функциональности осложняется наслоениями кода. Запуск тестов занимает полчаса, а релиз — час. Идея о переходе на новую версию фреймворка вызывает нервные подергивания. Вы узнаёте, что PostgreSQL имеет поддержку массивов, jsonb, полнотекстового поиска и lateral join, но ORM не позволяет использовать их в полную силу. Вы прочитали про TDD, но как писать в таком стиле, когда аналитик описывает сценарии, а фреймворк требует создания модели, контроллера и представления?

Как применить SOLID, если сущности наследуют от ORM?

Как избавиться от боли?

Постепенно, по мере изучения Clojure, и, наконец после прочтения Clean Architecture, я понял, как без боли написать приложение, где на первом месте стоит предметная область, а не фреймворк, где я принимаю решения, а не создатели фреймворков навязывают свои.

В какой-то степени книгу можно рассматривать как практический самоучитель по Clojure,
так что знание этого языка не требуется.

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

Как известно в кругу Erlang разработчиков: только Erlang разработчики знают как "жить" правильно а все остальные "живут" — неправильно. Не пытаясь оспаривать этот факт, приведем пример Clojure приложения в стиле Erlang, используя библиотеку Otplike.

Недели две назад InfoQ напомнил, что официальная поддержка Java 9 заканчивается… в Марте 2018г. (т.е. через 20 дней :)

Вот cсылка на официальный EOL от Oracle, в которой в разделе "Java SE Public Updates" черным по английскому говорится, что Java 9 будет поддерживаться до Марта 2018, а Java 8 — до Января 2019 (или позже) и Декабря 2020 (или позже).

Объединяем Websockets, Lisp и функциональное программирование. Но как?

Движение к функциональному программированию началось всерьез примерно десятилетие назад. Мы видели как такие языки как Scala, Clojure и F# стали привлекать внимание. Это движение было больше чем просто обычное восхищение «О, круто, новый язык!». Было что-то действительно побуждающее это движение — или мы так думали.

Всё больше набирает популярность паттерн использования каналов при создании
многопоточных приложений. Идея не нова, ее дизайн заложен ещё в далёком 1978 году
в виде CSP.Наиболее известная реализация сейчас повсеместно используется в Golang.

Мы же в статье рассмотрим реализацию CSP в core.async для Clojure, если интересно, добро пожаловать под кат.

Существуют библиотеки на различных языках, имеющие общие черты. Это compojure, sinatra, grape, express, koa и подобные.

У них схожий подход к роутингу. Они не накладывают никаких ограничений и не предлагают структуру для организации url. Разработчики в таких условиях склонны не заботиться о структуре и впоследствии получают плохо поддерживаемый код.

Другая общая черта — это однонаправленность. Т.е. определенному запросу соответствует определенный обработчик. Разработчики вынуждены прописывать url строками в шаблонах. Нет возможности указать в виде конструкции языка, какой url сгенерировать. Это приводит к тому, что в представлениях остаются мертвые ссылки, и нет способа найти их, кроме как протыкать все страницы.

Я расскажу, как улучшить поддерживаемость кода в экосистеме Clojure, и покажу, как:

1. организовать url'ы
2. структурировать код обработчиков
3. использовать языковые конструкции для генерации url

Привет, читатель! Если доводилось писать Selenuim-тесты чуть сложнее чем на пару полей ввода и одну кнопку, то эта статья может пригодиться.

Наверняка знакомо чувство неправильности происходящего, когда внезапно отказывался работать тест-кейс длиной в пару минут, вынуждая тыкаться вслепую, чтобы найти поломавшийся css- или xpath-селектор в сложном Single Page Application, раз за разом запуская этот медленный сценарий, только чтобы дождаться вывода лога в консоль. Оказывается, можно писать Selenium-тесты с комфортом!