Парное программирование очень клевая штука, особенно для ремоута. Лет 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 из-за такой разницы между языками.

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

За пару вечеров вышло собрать такую штуку, да еще и подключить к Figwheel.
https://github.com/roman01la/cljs-source-mapped-stack-traces

Kevin Lynagh (https://twitter.com/lynaghk) написал хороший пост о том, как с помощью type inference в ClojureScript получить максимум гибкости и производительности в использовании Hiccup в компонентах на React.

Существует несколько подходов к транслированию Hiccup в React:

Интерпретация (Reagent). Дает максимальную гибкость в рантайме в ущерб производительности.

Компиляция (Hicada). Максимальная производительность в ущерб гибкости.

Компиляция + Интерпретация (Sablono). Best of both worlds. Компилирует статическую часть Hiccup в React, а остальное откладывает на интерпретацию в рантайме.

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

Это продемонстрировано в статье: https://kevinlynagh.com/notes/fast-cljs-react-templates/

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

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

Примитивные тактильные взаимодействия можно передать через паттерны вибрации телефона + звук.

Со звуком окружения интереснее. Игроку в наушниках необходимо на слух определить источник звука в пространстве. Проще говоря, нужно проигрывать звуковые эффекты в 3D. А это означает обработка звука в реальном времени.

К счастью команда Chrome сделали модуль рендеринга аудио в пространстве поверх Web Audio API https://googlechrome.github.io/omnitone/. Изменение положения игрока в пространстве можно снимать с телефона с помощью Device Orientation API и таким образом «вращать» звуковое пространство вокруг игрока.

Можно даже задействовать Device Motion API для интерпретации резких движений как взаимодействий с объектами (дверь и т.д.).

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

Зато получилось подключить десктопный браузер к мобильному через WebRTC, чтобы обрабатывать все на десктопе и стримить в телефон.

Вышел такой себе «клиенсткий-бекенд», к которому могут подключаться несколько клиентов и теоретически бродить в слепую в одном мире, ориентируясь по звуку.

Модульная сборка JRE, которая появилась в JDK 9 (https://dzone.com/articles/jlink-in-java-9), дает интересные результаты.

Например запакованный uberjar с веб-сервером на кложе + минимальный JRE (только модуль java.base) весит всего 20Мб. Есть и плагин для Leiningen, который автоматизирует сборку кастомного JRE через jlink https://github.com/sunng87/lein-jlink

А при желании можно скомпилить все в нативный бинарник через GraalVM AOT для джавы http://www.graalvm.org/docs/reference-manual/aot-compilation/, но пока что он не поддерживает весь динамизм кложи, хотя уже есть удачные попытки сборки небольших проектов.

Слышали про новый браузер Next? https://next.atlas.engineer/

Браузер для лисперов, даже кейбиндинги Emacs-style 😀

Полностью расширяем, встроенный REPL, все как в Emacs. Кор на Common Lisp + pluggable рендеринг (webkit, gecko и т.д.)

На macOS работает только под Mojave. Автор не знает, как собрать приложение под несколько платформ в xcode 😂

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

Среди всех возможных портов WebKit выделяется WPE WebKit для embedded систем https://wpewebkit.org/ (обзорный доклад https://www.youtube.com/watch?v=klfE6m1oCkg)

Если коротко, то это WebKit из которого выбросили все лишнее, а остальное перевели на более производительные альтернативы.

Звучит интересно, но вроде бы у авторов нет цели ввести поддержку macOS и Windows. Из десктопов поддерживается только Ubuntu.

В свободное время пытаюсь разобраться в разработке Android приложений на Kotlin. Сейчас делаю Android версию ClojureScript REPL Replete https://replete.surge.sh/

В целом неплохо. В чем-то тулинг лучше, чем в React Native. Но возможности интерактивной разработки, конечно, не хватает.

В приложении ClojureScript выполняется в V8, для него есть Java обертка J2V8 https://github.com/eclipsesource/J2V8/. Время старта приемлимое, учитывая, что там около 9Мб скомпилированного JS, но могло бы быть и лучше.

В V8 есть возможность сделать дамп хипа и использовать его для почти мнгновенного старта https://v8.dev/blog/custom-startup-snapshots По факту это такой себе AOT для JS. Это успешно использует Node.js ClojureScript REPL Lumo https://anmonteiro.com/2016/11/the-fastest-clojure-repl-in-the-world/

J2V8 собирает V8 без возможности сериализировать хип, поэтому движок нужно собирать самому под все версии архитектуры arm. Это та еще боль 😕

Заметка про Kotlin. Мне, как разработчику, который почти не работал с Java, Kotlin вполне зашел (мнение после двух недель, ага). Совсем не страшно после JS (особенно если немного смотрел на TypeScript), но после кложуры некоторые вещи приходиться делать скрипя зубами.

Кажется, что язык позиционирует себя как более «функциональная» альтернатива Java, но наследние джавы вылазит на каждом шаге. Корутины пока пригодились так же, как и core.async в кложуре (не нужен).

Самая приятная фича: если вставить код на джаве в файл с котлин, то IDE на ходу транспайлит в котлин :D

Вчера попробовал стримить разбор Kotlin + JS, вышло написать что-то с React. Запись вот здесь (местами проседает звук) https://www.youtube.com/watch?v=_VeFnJHrmaI&t=313s

Собрал гайд по интеграции ClojureScript/Reagent в JS/React проекты. Пока что это единственный известный мне более-менее нормальный способ внедрить cljs в кодовую базу на js. По крайней мере уже не нужно писать руками экстерны т.к. компилятор научился выводить их в 90% случаев https://github.com/roman01la/reagent-react-integration

Как оказалось есть альтернатива — shadow-cljs. Сборщик сделан специально под интеграцию с NPM, все делает сам с минимальным конфигом https://github.com/thheller/reagent-react-integration/tree/shadow-cljs