Продолжаем писать собственные плагины для Obsidian. Первую часть статьи можете найти здесь. В ней мы:
Выяснили, что можно писать плагины даже проще, чем это предлагает делать официальная документация
Написали три маленьких плагина, которые уже вовсю используются на продакшене лично мной
Грозились написать четвертый финальный босс-плагин
Вот и приступим.
А вы уже прятали что-то внутри PNG? Базовый способ надежно спрятать что-то внутри картинки. И все на вашем любимом JavaScript!
После шумихи с Notion все ринулись кто-куда, но так сложилось, что по большей части все стали смотреть в сторону Obsidian. И Хабр заполонили статьи про Obsidian и плагины для Obsidian.
Правда, к моему сожалению на техническом ресурсе Хабр я почему-то не нашел ни одной статьи о том, как написать свой собственный плагин, а не как использовать кем-то созданные решения. Я считаю это либо досадным недоразумением либо своим неумением использовать поиск Хабра. Накидайте мне в комментарии, если я не прав, я приму к сведению.
А сейчас же я хотел бы заполнить сложившийся вакуум собственным гайдом.
В процессе разработки UI для игр Forza Horizon 3 и Forza Motorsport 7 я имел возможность поработать с потрясающими акриловыми матовыми элементами дизайна.
Вдохновлённый этим дизайном, я захотел создать похожий эффект при помощи HTML. В этом посте я расскажу о своих попытках создания красивого эффекта стекла, а также представлю пример кода и ассетов для тех, кто захочет попробовать реализовать эту методику самостоятельно.
Все так или иначе сталкивались с функцией или методом, который принимает объект и свойства в виде строки с которым нужно что-то сделать. Пример:
updateDate(user, "date");
И когда изменяется свойства объекта (user.date → user.birthday), компилятор его нормально скомпилирует и мы лишаемся возможности отловить баг на стадий разработки.
Нахожусь в процессе написания механизма торгового робота, работающего на Московской бирже через API одного из брокеров. Брокеров имеющих своё АПИ для МосБиржи катастрофически мало — мне известно только о трёх. При этом, когда я стал публиковать модули робота (и полностью выложу готовый механизм робота на GitHub), то стал получать непонимание — например, мне писали в комментариях — зачем придумывать велосипед, когда уже есть QUIK — популярная российская платформа для биржевых торгов. В Квике уже есть готовый функционал «импорт транзакций из файла» или таблица «карман транзакций». В тех же комментариях предлагали даже рассмотреть использование платформы 1С для робота, но оказалось, что торговля все равно будет осуществляться через импорт .tri-файла в Квик.
Лично мне Квик не очень нравится тем, что это программа для Windows. Хочется иметь механизм торгового робота, который был бы кроссплатформенным и легким — это позволит использовать его даже на «слабом» сервере. К тому же, много лет назад, когда Квик был единственной альтернативой для частного лица, невозможно было внутри одной Windows без использования виртуальной машины запустить несколько копий программы технического анализа с разными системами — для того, чтобы каждая из этих копий отправляла свои сигналы на покупку и продажу в соответствующий Квик. Это было нужно для разных торговых стратегий.
Предупреждаю, это будет относительно большая статья. Но советую дочитать до конца, особенно тем, кто сейчас учится или думает о построении плана обучения и своей дороги в программировании в целом. Этот пост основан на моем опыте: расскажу, как я нашел первую работу и обучался.
Можно сказать, это «краткое резюме» моей 9-летней карьеры в IT в качестве frontend разработчика. Обязательно будет интересно! Даже если местами будет казаться скучно, продолжайте читать — оно того стоит.
Я вас понимаю. Да – еще один. Но давайте посмотрим, вдруг правда?
Давайте определимся с тем, что такое удобно. Конечно, у нас разные представления об удобстве, поэтому я опишу свои с примерами из api react:
В веб-разработке часто возникает необходимость обрабатывать различные типы взаимодействий пользователя, включая короткие и длинные нажатия. В этой статье мы рассмотрим изящный способ реализации обработчиков для этих двух взаимодействий.
▎Зачем нужен Long Press?
Long Press — это взаимодействие, при котором пользователь удерживает палец на экране или кнопку в течение определенного времени. Это может быть полезно для вызова дополнительных действий, таких как контекстное меню, всплывающие подсказки или специальные функции, которые не должны выполняться при обычном клике.
▎Стандартное решение
Реализация обработчиков долгого и короткого нажатия на чистом JavaScript будет выглядеть примерно следующим образом:
В начале карьеры мне тоже казалось, что каждый разработчик должен следовать строгим правилам и рекомендациям. Я думал, что чем больше знаний, тем лучше результат. В итоге, передо мной открывался целый мир идеальных паттернов, архитектур и сложных решений. Но со временем я понял: важно не только читать и понимать теорию, но и уметь применить её в реальной жизни. И что ещё важнее — делать, а не спорить.
В этой статье я расскажу о своих ошибках, которые я допустил, пытаясь быть слишком «правильным». Как я заморачивался с кэшированием, пытался сделать универсальные компоненты и топил проект в лишних сложностях. Эти ошибки научили меня одному: не всегда нужно гнаться за идеальностью.
Давайте посмотрим, как я заморачивался с вещами, которые в итоге только усложнили задачу, и что из этого получилось.
Представьте ситуацию: ваша команда закончила интеграцию с API, все протестировала и подготовила релиз. А тут внезапно серверная команда меняет формат ответа. Фронтенд падает, QA злится, пользователи недовольны. Приходится вручную переписывать валидации, искать баги и терять дни, чтобы всё починить.
Как автоматически синхронизировать работу между бэкэндом и фронтендом? А между дизайном и фронтендом? Использовать генератор кода валидации! Написание своего решения поможет понять бизнес-логику проекта и создать валидаторы, которые максимально отвечают вашим требованиям. А реализация проще, чем кажется на первый взгляд – покажу это в статье на примере создания кастомного генератора на нашем проекте.
В первую очередь статья будет полезна фронтенд-разработчикам и командам, работающим над сложными веб-приложениями, особенно тем, кто активно взаимодействует с API, описанными через OpenAPI.
Внедрение нескольких сервисов с помощью одного токена — достаточно удобная механика в фреймворке Angular. Однако, можно столкнуться с неприятностью, что во всех местах, где нужно получить данный сервис, придётся как-то выбирать нужный инстанс из массива. Кто-то делает это напрямую, через метод массива find, кто-то регистрирует сервис-менеджер, который умеет возвращать нужный инстанс, однако оба варианта рождают неприятный бойлерплейт. В этой статье разберём подход по удобной и продвинутой регистрации multi-сервисов.
Brisa — это современный веб-фреймворк, который сочетает мощь серверного рендеринга и удобство клиентских компонентов. Он позволяет создавать быстрые, легкие и высокопроизводительные веб-приложения, минимизируя объем JavaScript, отправляемого в браузер. Поддержка веб-компонентов, гибкая интернационализация и возможность кроссплатформенной разработки с помощью Tauri делают Brisa универсальным инструментом для веб-разработчиков.
В этой статье мы подробно разберём, как начать работу с Brisa, изучим основные принципы и рассмотрим примеры кода.
Большое количество специалистов в области IT используют переводчики текста в своей работе, и я тому не исключение. Достаточно часто в вакансиях Системного администратора можно встретить требуемый навык - "чтение технической документации на английском языке", но, не всегда такая документация может быть очевидной в полной мере, даже имея базовый уровень английского языка, и как мне кажется, тут нечему стесняется. Для перевода текста чаще всего используется браузер, а также десктопные приложения, я же расскажу про альтернативу таким решениям, для перевода текста прямо в консоли Linux или Windows.
Приходилось ли вам работать с потоками в Node.js?
Когда я впервые столкнулся с потоками, я, мягко говоря, оказался в растерянности. Эта концепция была совершенно новой для меня. Я полагал, что смогу обойтись и без них, но вскоре понял, что в Node.js они повсюду. Даже такие ключевые модули, как fs и http, используют потоки "под капотом". Поэтому мне пришлось погрузиться в изучение этой темы и разобраться в том, как потоки работают.
В этом мне особенно помогло создание устойчивой ментальной модели, основанной на нескольких ключевых концепциях. В этой статье мы подробно рассмотрим эти концепции и сформируем ментальную модель потоков в Node.js.
На днях столкнулся с интересным вопросом. Что быстрее element.style.setProperty(свойство, значение)или element.setAttribute('style', 'свойство: значение')? На первый взгляд ответ кажется очевидным. Логика говорит нам, что setProperty должен устанавливать значение сразу в CSSOM, тогда как setAttributeвыставляет сначала атрибут style и уже потом значение атрибута будет разобрано в CSSOM. Таким образом, setProperty должен быть быстрее. Но действительно ли всё так однозначно? Давайте разбираться.
Начнем с того, что немного освежим мат. часть. Мы знаем, что стили описываются с помощью языка CSS. Получив строковое описание стилей на языке CSS, браузер разбирает его и составляет объект CSSOM. Интерфейс этого объекта представлен спецификацией https://www.w3.org/TR/cssom-1. Он следует принципам каскадности и наследования, изложенным в https://www.w3.org/TR/css-cascade-4.
Из выше указанных спецификаций мы знаем, что основной единицей CSS является "свойство". Свойству присваивается значение, характерное конкретно этому свойству. Если значение не задано явным образом, оно наследуется от выше стоящего стиля или, если нет вышестоящего, будет установлено initial value.
Набор свойств для элемента собирается в правила CSSRule. Правила бывают разных типов. Наиболее популярный тип - CSSStyleRule, определяющий свойства элемента. Такое правило начинается с указания одного из валидных селекторов и последующих фигурных скобок с набором свойств и значений <selector>: { ... }Имеются и другие типы правил, например CSSFontFaceRule, описывающий параметры подключаемого шрифта @font-face { ... }, CSSMediaRule - @media { ... } и др. Полный список в спецификации https://www.w3.org/TR/cssom-1/#css-rules.
Привет! Меня зовут Никита, и я тружусь в команде фронтенда платформы в Ozon. Платформа поставляет инструменты для создания и поддержки JS-проектов. В компании в настоящее время более 500 таких проектов. Мы прилагаем максимум усилий, чтобы разработчикам всех проектов было одинаково приятно работать с нашими инструментами.
Также мы предоставляем инструменты для создания JS-библиотек. И в этой статье я расскажу о том, как мы советуем создавать npm-пакеты. Отмечу, что это не касается UIKit-пакетов, — для них требуется довольно специфичный инструментарий, который заслуживает отдельной статьи.
Недавно у нас проходила актуализация инструментов, которая включала обновление версий Node, TypeScript и прочего. И мы обнаружили, что сейчас правильно упаковать библиотеку ой как нелегко, особенно с началом активной фазы по отказу от CommonJS. В идеале очень хочется иметь инструмент, который бы просто работал. В open-source есть парочка вариантов (unbuild, pkgroll, dnt), но выбрать подходящий мы пока не смогли. А написать свой — довольно трудоёмкая задача. В будущем мы обязательно обзаведёмся таким инструментом, а пока просто погрузились в тему и подготовили для наших разработчиков рекомендованные сетапы, которыми сейчас поделимся и с вами.
Начнем с небольшой истории. Как-то раз я с размахом накинулся на проект — в духе нынешних фреймворков всё было обложено компонентами, декларативный стиль царил, все шло идеально… ну почти. Дошел я, значит, до нужды контролировать DOM-узлы напрямую. И что вы думаете? Прямого доступа нет, React закрыл от меня этот мир, сидит и ухмыляется: мол, мы тут за производительность боремся, зачем тебе что-то трогать руками?
Но мы не из тех, кто сдаётся, верно? React предлагает своё решение — рефы, и именно о них сегодня пойдет речь.
Как избежать типичные ошибки при внедрении микрофронтов и какие инструменты упрощают жизнь разработчикам.
Рассмотрим плохие примеры разделение кода приложения, т.е. когда "архитектор" или лид проекта, не умеют микрофронты готовить. А разработчикам нужно с этим жить.
Ты приходишь в новую компанию, всё кажется крутым: светлый офис, дружелюбная команда, проекты мечты. И тут начинается...
Сборник фронтендерских болей.
