Добро пожаловать в Angular 11


Прототипно-ориентированный язык программирования

Введение
Библиотека круговых интерфейсов v2.0
Круговая CAPTCHA
Перенос библиотеки с JavaScript на QML
Демонстрационное мобильное приложение
Заключение
Предыдущая статья была вводной к вопросу разработки круговых интерфейсов. В ней рассмотрены определение, классификация, принципы построения круговых интерфейсов, а также подход к их проектированию. Данная статья описывает основные изменения в библиотеке, которую я разрабатываю для облегчения и ускорения процесса создания круговых интерфейсов.
Во-первых, вышла вторая версия библиотеки на JavaScript, в которой реализованы круговые элементы управления.
Во-вторых, разработанная библиотека получила реализацию на QML, для демонстрации возможностей которой выпущено мобильное приложение под Android.
Когда я впервые услышал про compliant-механизмы, был весьма впечатлен. Хоть они и окружают нас в повседневности — в виде застежек рюкзака, кнопок мыши или колпачков от шампуней, — мы редко задумываемся о концепции таких устройств.
Если говорить кратко, в compliant-механизме для обеспечения его технических характеристик используют деформацию. В то время как в традиционной технике (rigid body) гибкость зачастую является негативным качеством материала, сompliant-механизмы используют ее для передачи силы и движения в нужном направлении, вместо соединений из нескольких подвижных деталей.
Выпуск библиотеки — это непростая задача, но с нужными инструментами это проходит намного легче. На конференции HolyJS Ундже Ли (Eunjae Lee) показал, как можно автоматизировать процесс релиза, как сделать его асинхронным и коллаборативным.

Ниже — видео и перевод этого доклада.

Что лучше для web-приложений - монолит или микросервисы? Многие ответят на этот вопрос, что, мол, все инструменты хороши, если их использовать по назначению. В таком случае у меня, как у человека, в силу своего возраста, довольно консервативного и неохотно воспринимающего непроверенные временем концепции, возникает другой вопрос - а чем хорош монолит? Где его ниша? Стоит ли переключаться на микросервисы или монолит ещё не изжил себя и на мой век хватит?
В фокусе моих интересов не гигантские web-приложения типа Gmail, Facebook, Twitter, а web-приложения, созданные на базе таких платформ, как Wordpress, Drupal, Joomla, Django, Magento и им подобным. Под катом мои субъективные мысли на этот счёт. Ничего нового - всё те же 33 буквы кириллицы и 26 букв латиницы вперемешку.
Привет, Хабр!
Я время от времени провожу собеседования, и когда вопрос касается React key, чаще всего я вижу недоумевающий взгляд, намекающий “Да, там и спрашивать вроде нечего?”. Если Вам кажется React key понятным и простым, тогда давайте проведем мини собеседование (данная статья является расшифровкой видео).
Мне очень сильно импонируют namespace'ы в таких языках программирования, как Java и PHP. Настолько сильно, что я даже как-то запилил о них статью на Хабре. С тех пор прошло уже почти два года, но namespace'ы в Javascript за это время так не появились. "А если бы я делал namespace'ы в JS для самого себя, то какими бы они были?" - подумалось мне. Под катом - мои соображения, какие же namespace'ы мне нужны в JavaScript'е.



За свою карьеру я успел поработать со множеством языков программирования. Писал flash-игры на ActionScript 3 и Android-игры на Java, сервера на Java, Scala и NodeJS (JavaScript), скрипты на Python, веб и мобильные приложения на React (JavaScript). И на каком бы языке я не писал, меня не покидало ощущение, что синтаксис этого языка слишком многословен, полон излишеств, шума и синтаксического бойлерплейта, мешающего пониманию написанного кода.
Уже тогда я начал делать первые попытки создать свой собственный язык программирования, лишенный этих недостатков. Но для начала мне надо было определиться с тем, что именно не так с существующими языками и каким образом можно формализовать параметры "качества" языка, чтобы начать их улучшать. После долгих размышлений и сравнений я выработал для себя несколько параметров
Приветствую! Если вы зашли на эту статью, значит скорее всего вам крайне неохота лезть в официальную документацию (а очень зря. Она и написана подробно, и имеет перевод на русский язык) и вы пришли за простым решением вашей проблемы — написание кросс-платформенного приложения для компьютера с использованием лишь Web технологий. предлагаю не тянуть, и сразу начать. Но т. к. это первая статья, думаю стоит рассказать в двух словах о том, что же вообще такое Electron JS и для чего оно нужно.



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

Добрый день, уважаемые читатели. Эта статья посвящена проблеме, с которой сталкиваются разработчики более-менее серьезных веб-сайтов, а именно – проблеме автоматического обновления скриптов в браузере пользователя после деплоя.
Суть проблемы заключается в том, что одностраничное приложение, загруженное в браузере пользователя, не знает о том, что скрипты были только что изменены, и, следовательно, необходимо обновиться. С точки зрения пользователя это выглядит как непонятные ошибки, возникающие на ровном месте, или как отказ приложения выполнять свои функции. Все это – следствие того, что версия скриптов на сервере изменилась, и приложение просто не может их найти и загрузить.
Конечно, все решается нажатием на F5, но в данной статье я покажу, как можно автоматизировать это действие, избавить пользователя от головной боли и сделать это красиво.




Некоторые проекты зачастую требуют специфичные версии локально установленных программ. Это может быть как определенная версия node.js или npm (например, npm@7 с поддержкой workspaces), так и определенная база данных, менеджер пакетов и другие утилиты, которые нельзя установить из npm. Зачастую команды фиксирую версии в чатиках, readme или вики.
npm позволяет задекларировать в package.json файле необходимые версии node и npm, но никак не проверяет их. Чтобы исправить это и расширить список инструментов был написан небольшой npm пакет engine-version. Пакет работает очень просто: сначала он считывает описание необходимого софта из package.json, а затем смотрит установлена ли программа и совпадает ли установленная версия описанной. И если проверки прошли неудачно, отображается список ошибок.
Всем привет! Идеологически Quarkly – это проект, который призван упростить жизнь веб-разработчикам и веб-дизайнерам. В этом посте я коротко расскажу, за счет чего это возможно.
Прежде всего, давайте посмотрим, как выглядит типичный цикл разработки веб-приложения в 2020 году? Есть команда. В этой команде есть дизайнер и разработчик. Первый создает дизайн-спецификацию в Figma. Второй, на основе дизайн-спецификации, создает компоненты, переносит тему. Результат своей работы программист показывает дизайнеру в Storybook. Дизайнер его проверяет и утверждает проект, если всё хорошо. Далее он начинает создавать макеты, а разработчик верстает их при помощи компонентов из спецификации.
