Привет!

Однажды, на одном проекте, где мне довелось работать только фронтом, мне пришлось столкнуться не с вездесущим REST, и не с хайповым GraphQL, а со старичком RPC, а именно — его вариантом JSON-RPC 2.0.

И знаете, с тех пор (когда делаю и бэк) я использую почти всегда именно его.

Холиварить не будем, но если вы тоже сторонник использования JSON-RPC, то знаете, что в случае с HTTP смотреть запросы, например в Chrome DevTools / Network, не очень-то и удобно. Эндпоинт у нас почти всегда один, статус всегда 200 (ну, если сервер не завалился вообще). Вывод — нужно расширение к devtools. И вот, небольшой набросок (пулреквесты приветствуются): github.com/kityan/json-rpc-viewer
Полезное и хорошее замержим и обновим версию в сторе, а вообще, форкайте и прикручивайте преферансы и куртизанок по желанию.

Возможно, я только сейчас разглядел, а всё уже давно знают, но оказывается, что в Chrome 70 сделали вот такое: The ontouch* APIs default to disabled on desktop

Соответственно, если в своём коде вы опирались на наличие ключей 'ontouch*' в document или window, ваш код перестанет определять, что работает на touch-устройстве.

Вы пишите сервер на Node.js, который принимает входящие TCP-соединения и ведёт с клиентами нетривиальный диалог по нестандартному протоколу? Возможно вам будет интересен пример, который я развиваю в своих проектах. Что я имею ввиду под нетривиальным диалогом?

Давайте сравним.

Уверен, всем приходилось работать с интерфейсами drag-and-drop, а многим — разрабатывать ПО с таковыми. В большинстве случаев факт drop'а объекта-draggable на объект-target устанавливается по факту попадания координат курсора мыши в bounding box объекта-target в обработчке событий типа mouseUp, dragStop и прочих.

Так работают почти все примеры, которые мне встречались. Но некоторое время назад, при реализации модуля интерактивного задания для образовательного ресурса, я столкнулся с тем, что такой подход не очень удобен. Основная причина — объекты-target существенно меньше объектов-draggable. Поэтому целится мышью неудбоно и утомительно. Таща крупный объектами-draggable, пользователь полностью перекрывает объект-target и не видит куда объект падает.

Совсем недавно мы столкнулись с необходимостью HTML-верстки большого количества разнообразного учебного (школьная программа) материала.

К сожалению, в ряде случаев пришлось отдельно готовить изображения с текстовыми блоками, которые были снабжены хитрой версткой. Это усложняет процессы HTML-верстки и внесения правок. Благодаря замечательному MathJax, мы смогли оптимизировать верстку в части математики, физики и неорганической химии, однако органическая химия осталась непобежденной. Да, есть пакеты для верстки структурных формул в LaTex, но в MathJax их поддержки нет.

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

Dataflow + G = LabVIEW

Некоторое время назад я сменил специализацию. Это был не просто переход к другому языку программирования или сосредоточение на иной области задач, но и весьма ощутимое изменение парадигмы, которой я придерживался. Год назад я окунулся в мир dataflow и визуального программирования. Наиболее ярким и мощным представителем этой ветви средств разработки является LabVIEW (National Instruments). К сожалению, информации на Хабре по этой теме практически нет, поэтому я и попытаюсь заполнить пробел.

Я не претендую на полноту изложения материала, не собираюсь писать учебное пособие — их достаточно. Главная задача, которую я ставлю перед собой — это освещение концепции LabVIEW и некоторых технологий создания ПО в этой среде. Возможно, кому-то это поможет сделать оптимальный выбор средства разработки, кого-то — подтолкнет к решению задач в своей области новым методом. Наконец, полезно просто расширить кругозор.