Я не шутил по поводу языка :D

Просили публиковать сюда материалы/задания, которые используем в курсе. Вот репозиторий с материалами по интро в язык, пользуйтесь https://github.com/roman01la/amsterdamjs-clojurenoscript-workshop

Под Rust сделали персистентные структуры из Clojure https://docs.rs/im/11.0.0/im/ 👏

Чуваки из FB научили Prepack (AOT компилятор для JS) компилить в LLVM и в нативный бинарник 🤔 https://github.com/facebook/prepack/pull/2264

Есть предположение, что полноценный AOT к JS можно применить используя более строгие суперсеты языка или даже языки компилирующиеся в JS. Например Elm, PureScript и т.д., где побочные эффекты вынесены за пределы программы. По крайней мере на небольших примерах с Elm Prepack выдает работающую программу, в отличии от того, что обычно получается на выходе после применения AOT к обычной приложеньке на чистом JS, где побочные эффекты никак не контролируються.

Если подумать то AOT как раз больше имеет смысла применять к таким языкам, чтобы упрощать/развертывать их абстракции (например структуры данных) в максимально простой js код на этапе сборки проекта, вместо того, чтобы все это выполнять в рантайме.

Русскоговорящий чатик Clojure Russia переезжает из Clojurians Slack в Telegram 👉 https://news.1rj.ru/str/clojure_ru

Все же очень круто, что кложура дает возможность лаконично выражать абстракции в виде данных.

Делаю прототип визуального редактора с набором простых блоков. Блоки довольно просто описать в стиле Hiccup, по структуре максимально приблежены к доменной области (свойства блоков в визуальном редакторе). Спекой неплохо выходит описать блоки и структуру, потом валидировать и разобрать все это на AST.

Дальше описываем несколько мультиметодов для транслирования в Reagent Hiccup и получаем UI.

(s/def :element/x int?)
(s/def :element/y int?)
(s/def :element/color string?)

(s/def :element/text
  (s/cat
    :tag #{:text}
    :attrs (s/keys :req-un [:element/color])
    :text string?))

(s/def :element/rect
  (s/cat
    :tag #{:rect}
    :attrs (s/keys :req-un [:element/x :element/y])
    :children (s/* :visual/element)))

(s/def :visual/element
  (s/or
    :rect :element/rect
    :text :element/text))

(defmulti -compile-visual first)

(defmethod -compile-visual :rect [[_ {:keys [attrs children]}]]
  (let [{:keys [x y]} attrs]
    `[:div {:style {:left     ~x
                    :top      ~y
                    :position "absolute"}}
      ~@(map -compile-visual children)]))

(defmethod -compile-visual :text [[_ {:keys [attrs text]}]]
  (let [{:keys [color]} attrs]
    [:span {:style {:color color}}
     text]))

(defn visual->hiccup [element]
  (when (s/valid? :visual/element element)
    (-> (s/conform :visual/element element)
        -compile-visual)))

(visual->hiccup
  [:rect {:x 10 :y 100}
   [:text {:color "#000"} "text"]])

(comment
  [:div
   {:style {:top 100, :position "absolute", :left 10}}
   [:span {:style {:color "#000"}} "text"]])

Парное программирование очень клевая штука, особенно для ремоута. Лет 5 назад мы делали pairing на постоянной основе, в офисе.

Для офиса это работало неплохо, хорошо заходило для введения новичков в курс дела. На себе чувствуется сильнее именно во время удаленной работы, когда ты отдален от всех сотрудников.

Асинхронное общение через чат немного помогает «прочувствовать атмосферу», но личное общение много лучше. Даже работа над общей задачей, где один просто смотрит как другой пишет код, часто имеет кучу плюсов: общение, обмен опытом, свежий взгляд на решение проблемы и т.д.

Другой аспект, что на разработку фичи в паре может уйти больше времени, чем если бы ты сам занимался этим, но в итоге качество на выходе заметно лучше (если конечно вы не поссорились в процессе 😂).

p.s. Все это imo и индивидуально.

Если планируете в следующем году посетить конференцию в Европе и устали от больших конф, сходите на BOB в Берлине https://bobkonf.de/2019/en/, небольшая конфа про немейнстримное ФП.

Или месяцем ранее на ламповую ClojureD https://clojured.de/

За последние года 3-4 в мир JavaScript пришли функциональное программирование и иммутабельные данные. Но по факту ничего толком не прижилось. Возможно средний разработчик стал более дисциплинированным после прочтения 100500 статей о чистых функциях.

Функциональный стиль. Есть каста фронтендщиков, которые упарываются по Ramda и пишут в pointfree стиле в JS. Остальные используют всем известные функции высшего порядка из стандартной библиотеки языка и всегда используют const.

Иммутабельность. Immutable.js так и остался технологией «сбоку». В большинстве случаев его не используют в JS из-за неидиоматичности по отношению к языку, а не от надуманных проблем с производительностью. По той же причине никто не использует Map и Set из ES2015. Сложно заставить себя писать m.get("key") после короткого m.key.

Поэтому на замену функциональному Redux и неидиоматичному Immutable.js пришли MobX и immer. А для любителей функциональщины Facebook сделал Reason и перетащил туда всех недовольных забагованным тайпчекером Flow (который написан на OCaml).

Кстати, в 2017м было опубликовано предложение ввести иммутабельные коллекции в JS и добавить для них литералы https://github.com/sebmarkbage/ecmanoscript-immutable-data-structures

Все на выборы! ✅

В мире кложуры уже почти год существует организация «Clojurists Together» https://www.clojuriststogether.org/ цель которой поддерживать экосистему Clojure и ClojureScript финансируя open source проекты сообщества. В этом году финансирование получили уже 8 популярных проектов.

Мейнтейнеры подаются с заявками на финансирование своих проектов. Сейчас это около $5,400 на три месяца. Каждый квартал выбирается 2 проекта. Выбирает их коммитет организации. Раз в году проводится голосование для переизбрания членов комитета, подать заявку может кто угодно. Членов коммитета выбирают контрибьюторы организации. Контрибьютором может быть отдельный человек или целая организация (часто компании использующие Clojure). Вкладывают от $5 и до бесконечности. Из вкладов формируется финансирование выбранных проектов.

Время от времени Clojurists Together проводят опросы среди сообщества, чтобы финансировать проекты, которые действительно важны для экосистемы. А в их блоге мейнтейнеры каждый месяц публикуют отчет о проделанной работе https://www.clojuriststogether.org/news/july-2018-monthly-update/

По-моему это очень крутая инициатива. Она не только дает возможность заработать на open source, но и поддерживать жизнь и улучшать популярные библиотеки, которые используют сами контрибьюторы 👌

Один из инженеров в Pitch долго мучался с флоу взаимодействия с интерактивными объектами на экране, и в итоге пришел к стейт машине, которая действительно привнесла больше ясности в реализацию всех взаимодействий. И добавлять новые взаимодействтия тоже стало много проще и понятнее.

т.к. состояния и переходы описаны в виде данных в одной мапке, то уже можно быстро разобраться, что происходит, а еще можно визулизировать в graphviz https://github.com/jebberjeb/fsmviz

Недавно в моем айфоне перестала работать кнопка home и я пересел на Xiaomi redmi 5. За свои $200 это отличный телефон, кроме камеры.

И т.к. для разработки под Android никаких платных лицензий не требуется, то я решил посмотреть как там React Native.

Если коротко, то RN лучше, чем года 3 три назад, когда я работал с ним. А Xiaomi говно, которое для установки приложения в dev режиме требует доступ к серверам в Китае 😾

В итоге попробовал Expo SDK https://expo.io и это оказалась клёвая штука!

Самое удобное: можно запустить приложение через приложение-контейнер, которое устанавливается из стора. Ну и в придачу немало компонентов из коробки. В общем можно довольно быстро собрать несложное приложение.

В тему об альтернативах нативной мобильной разработке. Flutter выглядит довольно интересно https://flutter.io/

Dart 2 тоже неплохой. Особенно порадовал тулинг для Flutter в IntelliJ IDEA, ничем не уступает React Native. Есть визуальный дебаггер UI и отлично работает hot-reload.

Интересно, что Flutter использует для рендеринга Skia https://skia.org/, графический движек из Chrome. Выходит, что весь UI на Flutter полностью платформонезависим и, в отличии от React Native, нету моста между JS и нативной частью (JS там вообще нету).

Система компонентов в чем-то напонимает React (классы, метод render и локальное состояние компонента). Вместо FlexBox для лейаутов дают набор примитивных компонентов с разными свойствами поведения блоков (https://flutter.io/docs/development/ui/layout#flutters-approach-to-layout).

Экосистема компонентов конечно далека от, того, что есть в React Native, но в целом Flutter выглядит как хорошая, более надежная альтернатива для тех, кому не страшно изучать еще один язык.

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

Дело в том, что браузеры, в данном случае Chrome, даже при наличии карт кода (source maps) все равно показывают скомпилированный JS код во фреймах стектрейса. По привычке конечно это можно разобрать, но в целом не очень приятно смотреть на неизвестную простыню, которую вместо тебя писал компилятор.

Если разобраться, то становиться понятно, почему браузеры не показывают оригинальный код в стектрейсе. Любой язык не из семьи суперсетов JS скорее всего будет сильно отличаться от JavaScript, и конструкциями и семантически. Карты кода не всегда могут досконально описать соответствия между оригиналом и скомпилированным JS из-за такой разницы между языками.

Но было бы удобно показать хотя бы строку в оригинальном коде, на которую ссылается скомпилированный код через карту кода.