Это первая глава перевода небольшой книги о языке Janet за авторством Иана Генри (Ian Henry). В этой книге раскрываются различные аспекты работы с языком, обьяснение синтаксиса и некоторых приемов программирования.
Внимание, в этой публикации содержатся скобочки! Люди с непереносимостью Лисп-подобных языков, вас предупредили.
История одной оптимизации во время мастер-класса Clojure Minecraft
В июне компания JUXT приняла участие в ClojureD, ежегодной замечательной конференции по Clojure в Берлине. В течение дня проводился ряд семинаров, на которых рассказывалось о конкретной идее или инструменте и предлагалось поработать с ними. Наша группа решила посетить семинар "Изменим мир (Minecraft) с помощью кода", который проводили Арне Брассер (Arne Brasseur), Ариэль Алекси (Ariel Alexi) и Фелипе Баррос (Felipe Barros). В этом посте рассказывается о том, как мы использовали полученные на семинаре знания для создания изображений в игре и оптимизировали код с помощью Tufte.
Некоторое время назад на одном из проектов по работе я столкнулся с определенными требованиями, которые сразу же разожгли мой живой интерес разобраться с возможностями их обхода, попутно применив свой прошлый опыт написания фреймворков, интерпретаторов и т.п. В результат получилась вполне рабочая технология, позволяющая обходить с моей точки зрения лишние требования в проекте. За конкретикой прошу под кат.
В первые несколько лет реализации программного проекта можно добиться многого. С небольшой командой и правильными инструментами мы можем быстро предоставить функциональные особенности, которые удовлетворят как компании, так и их клиентов. На ранних стадиях проекта доставка часто приоритетнее архитектуры, но архитектура должна развиваться, если мы хотим, чтобы программное обеспечение разрабатывалось и поддерживалось в долгосрочной перспективе. Любой проект, который живет дольше нескольких лет, будет претерпевать изменения. Бизнес-требования поменяются, разработчики приходят и уходят, сервисы платформы, от которых зависит программное обеспечение, устаревают и заменяются, среды развертывания меняются, а новые технологии предлагают новые возможности, в то время как прежние технологии устаревают.
Роберт К. Мартин (Robert C. Martin) (дядя Боб) назвал пять основных принципов проектирования программного обеспечения SOLID. Такой акроним помогает людям легче запомнить их. Мне очень нравятся подобные мнемоники, потому что всем нам нужна помощь для фиксации в памяти необходимой информации. Чем проще закрепить знания, тем большему мы способны научиться.
Благодаря большому опыту проектирования программного обеспечения, эти принципы были разработаны для того, чтобы помочь создать ПО, которое можно поддерживать в работоспособном состоянии на протяжении длительного времени. Это благо для мира ОО (object-oriented — объектно-ориентированный), что об этих и подобных принципах так много говорят. Они были идентифицированы, переработаны, названы и кодифицированы. И теперь можно открыто говорить о них, при этом люди понимают, что вы имеете в виду. Такого рода вещей, как ни странно, совершенно не хватает в мире функционального программирования.
Краткий экскурс в синтаксис Clojure, который настолько лаконичен, что вы сможете прочитать этот раздел примерно за 15 минут.
”Если вам нравятся Руби, Свифт, Дарт, Эликсир, Эльм, С++, Питон или даже С, используйте их ради бога. Но выучите Кложур, и выучите его хорошо” — Дядя Боб (твит, а также твиты: 1, 2, 3).
Статей о Clojure написано много, цель этой — дать свое видение некоторых преимуществ языка для кросплатформенной разработки на Flutter. Ориентируюсь в первую очередь на dart-разработчиков, но статья может быть интересна всем, кто работает с Clojure и/или Flutter.
16 апреля зарелизился ClojureDart, а это значит, что для любителей Clojure открылась возможность писать мобильные, веб- и десктоп-приложения на Flutter. Зачем использовать для этого Clojure, как бы очевидно это ни было, выходит за границы фокуса статьи.
На текущий момент инструменты еще не отшлифованы, нет репла(!) и автодополнений для dart-интеропа, но пользоваться можно, и некоторые плюшки кложуры уже показали себя (например, nest-макрос, убирающий проблему вложенности).
В этой статье хочу рассказать, как написать свое первое flutter-приложение на Clojure, какими инструментами удобно пользоваться, где искать ответы на вопросы. Статья для тех, кто имеет хотя бы минимальный опыт работы с Clojure.
Этот пост служит для того, чтобы освежить в памяти, а некоторых познакомить с базовыми возможностями функционального программирования на языке Python. Материал поста разбит на 5 частей:
Главная задача этого поста – показать один мало применяемый на языке Python архитектурный шаблон под названием «функциональное ядро - императивная оболочка», в котором функциональный код концентрируется внутри, а императивный код выносится наружу в попытке свести на нет недостатки каждого из них. Известно, что функциональные языки слабы при взаимодействии с «реальным миром», в частности с вводом данных пользователем, взаимодействием с графическим интерфейсом или другими операциями ввода-вывода. В рамках такого подхода весь императивный код выталкивается наружу, и внутри остается только функционально-ориентированный.
Я попытаюсь проанализировать некоторые часто повторяющиеся критические замечания в адрес Lisp, чтобы пролить свет на этот вопрос и на то, почему его так часто задают.
Позвольте мне начать с пары слов для тех кто не в курсе. Lisp - это семейство языков, включая Common Lisp, Emacs Lisp и несколько диалектов, которые...
(defn simple-component []
[:div
[:p "I am a component!"]
[:p.someclass
"I have " [:strong "bold"]
[:span {:style {:color "red"}} " and red "] "text."]])
Неделю назад в издательстве "Ридеро" вышла книга "Clojure на производстве". Как ее автор, расскажу о ней подробнее: что внутри и кому она полезна.
Это книга о том, как применять Clojure в настоящих условиях: не сортировать списки в олимпиадных задачах, а поднимать веб-приложения, строить системы, писать тесты. Мой опыт с Clojure показывает, что переход от теории к практике происходит болезненно. Руководства обещают чистоту и неизменяемость, но на практике нам дают код, полный побочных эффектов и состояния.
Это книга — попытка облегчить погружение в практику. Одновременно хочу развеять ложные надежды: Clojure — прекрасный язык, но и в нем не бывает чудес.
От других материалов по Clojure книга отличается следующим. Прежде всего, это не перевод. Я не зря делаю на этом акцент во вступлении. Проблема переводов в том, что в издательствах не понимают технические термины и пытаются их адаптировать. Token становится маркером, trait — чертой, persistence — сохранностью. Формально перевод корректный, но пропадает живость описания, и к нему падает интерес. В своей книге я не срезал углы: если у слова нет однозначного перевода, я ставил английский вариант — тот, в котором мы видим его каждый день.
Привет! Меня зовут Рома, я работаю iOS-разработчиком в Exness. А кроме того, пишу на Clojure и инвестирую.
Сегодня я расскажу о том, как оценивать опционы. Это вводная статья и заработать миллион, используя предложенный способ, вряд ли получится. Тем не менее, это хорошая основа для понимания более сложных методов оценки.
При создании приложения, активно взаимодействующего со сторонними сервисами и системами, часто требуется обеспечить обмен информацией с ними, односторонний или двусторонний
Я написал книгу, предварительный релиз, о создании веб-приложений с нуля.
Я прочитал много книг по программированию, но, часто, после прочтения у меня оставался только один вопрос — Как мне применить эти знания на практике?
Предположим, вы разработчик системы автоматизации, портала или интернет-магазина.
Добавление новой функциональности осложняется наслоениями кода. Запуск тестов занимает полчаса, а релиз — час. Идея о переходе на новую версию фреймворка вызывает нервные подергивания. Вы узнаёте, что PostgreSQL имеет поддержку массивов, jsonb, полнотекстового поиска и lateral join, но ORM не позволяет использовать их в полную силу. Вы прочитали про TDD, но как писать в таком стиле, когда аналитик описывает сценарии, а фреймворк требует создания модели, контроллера и представления?
Как применить SOLID, если сущности наследуют от ORM?
Как избавиться от боли?
Постепенно, по мере изучения Clojure, и, наконец после прочтения Clean Architecture, я понял, как без боли написать приложение, где на первом месте стоит предметная область, а не фреймворк, где я принимаю решения, а не создатели фреймворков навязывают свои.
В какой-то степени книгу можно рассматривать как практический самоучитель по Clojure,
так что знание этого языка не требуется.
