JavaScript *

В этой статье я расскажу про личный опыт написания шахматной программы на языке TypeScript. С какими проблемами столкнулся и пути к их решению :-)

Подписание документов — неотъемлемая часть многих бизнес-процессов. Будь то заключение трудового договора, выдача материальных ценностей или оформление счетов: часто в таких случаях необходимо распечатать документ и подписать его. Чтобы упростить и автоматизировать этот процесс, мы разработали решение, которое позволяет получать подписанные документы прямо в 1С, исключая необходимость печати, подписи и последующего сканирования.

Бу! Испугался? Не бойся. Angular 19 уже не за горами и представляет новый мощный примитив, называемый linkedSignal, который поможет вам управлять сложным состоянием в ваших приложениях. Это альтернатива использованию effect для простого обновления сигнала на основе изменения другого сигнала. В прошлом мы видели, как сообщество обсуждало, чтобы избегать использования effect и вместо этого использовать computed для сброса сигналов на основе изменения другого сигнала.

Всем привет и добро пожаловать в мой хабр про интересные задачи и их решения в моей ежедневной работе. Уверен, что каждый QA (и не только) сможет найти здесь что-то интересное и полезное. Начнем!

Пару недель назад я взял задачу по написанию и настройке автотестов видеоплеера для разных платформ (Windows, MacOS, iOS и Android). Решил, что использовать Selenium в связке с NodeJS будет хорошим вариантом, так как именно этот фреймворк позволяет работать не только с десктопными, но и с мобильными браузерами (в отличие от того же Cypress).

Посмотрим, что у меня получилось и с какими трудностями я столкнулся при работе с iOS-устройствами.

Так ли производителен WebAssembly в сравнении с JavaScript как о нем говорят? Какие подводные камни могут ожидать при попытке ускорить CPU-bound задачи и в каких ситуациях он must have? Автор предлагает рассмотреть один кейс и разобраться в этих вопросах на практике

После почти 18 месяцев разработки, включающей тысячи коммитов от десятков участников, Svelte 5 наконец‑то стабилен.

Это самый значительный релиз в истории проекта. Svelte 5 — это полная переработка: ваши приложения станут быстрее, меньше и надежнее. Вы сможете писать более последовательный и идиоматичный код. Новичкам в фреймворке предстоит изучить меньше материала.

После 6 лет разработки команда React Native представила полностью переписанную архитектуру фреймворка (0.76) – самое значительное обновление с момента создания React Native. Это результат масштабной работы над улучшением производительности, стабильности и возможностей платформы.

В данной статье мы подробно рассмотрим различия между операциями очистки (clearing), сброса (resetting) и восстановления (restoring) моков в процессе тестирования программного обеспечения.

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

Проксирование реестра npm, ignore-scripts и "крышечки" — основы основ, о которых не знают в 99% компаний, где пишут на Node.JS

Задумывались ли вы, где можно применить навык решения задачек а-ля литкод изи? Я встречаюсь с ними частенько, главное просто присмотреться.

Например, на Linked.in недавно ввели "игры". Я как-то глянул на них на послеобеденном кофе.

Консоль браузера — это инструмент, о котором многие знают, но лишь немногие используют его возможности в полной мере. Для большинства QA-инженеров она остаётся чем-то вроде диагностической панели: открыть, увидеть ошибку, закрыть. Однако её потенциал значительно шире. Я убедился в этом на собственном опыте. Привет, Хабр, меня зовут Алексей Иванов, я занимаюсь тестированием в компании «Самолет», и, помимо ежедневной работы с продуктом, организую митапы по тестированию в Москве. Участвуя в таких крупных конференциях, как Heisenbug и SQA Days, я заметил, что многие мои коллеги используют консоль исключительно для отслеживания ошибок на сайте. Но что, если взглянуть на неё шире? 

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

В контексте вашего вопроса, если вы преобразуете картинку в векторное отображение с картой высот, это может означать, что вы создаёте векторную графику, которая также включает информацию о высоте или рельефе, что может быть полезно, например, в 3D-моделировании или при создании карт.

Сегодня поговорим о объектах, объектной архитектуре и способах взаимодействия с ними на примере языков программирования Python и JavaScript.

Получилось небольшое исследование, противопоставляющее прототипирование и ООП.

Давайте разбираться!

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

Вы запутались в сложных графах зависимостей и бесконечных правках кода? Nexus-IoC – это лёгкое, это мощное решение для внедрения зависимостей в проектах на TypeScript. Созданная как альтернатива Inversify, эта библиотека поможет вам легко управлять модулями, находить ошибки до их появления в продакшене и даже визуализировать граф зависимостей вашего приложения!

В статье я расскажу, какие проблемы решает Nexus-IoC, как начать с ним работать и как эта библиотека может сделать разработку более управляемой и предсказуемой. А также поделюсь планами на будущее.

Привет Хабр, let's set the future.

Недавно у меня появилась идея фикс: 'Хочу собственного AI ассистента'. Казалось бы, нет никаких проблем - рынок предлагает массу готовых решений. Но моя вечная паранойя про утечку данных и стремление сделать все самому взяли верх. Решил поэкспериментировать и собрать ассистента своими руками, да еще как-то с учетом будущих возможностей для гибкой настройки. Времени на оптимизацию производительности и эстетический вид кода у меня не было, 'хочу здесь и сейчас', поэтому let me introduce this shit.

Привет, Хабр! В прошлый раз мы с вами создавали «Игру жизни» на Godot. Движок показал себя отлично, но для такой простой задачи это всё равно что забивать микроскопом гвозди. Особенно когда речь идёт о веб‑экспорте.

В последнее время стоит заикнуться про генерацию изображений, как все сразу вспоминают про нейросети. Stable Diffusion, Midjourney и прочие модели впечатляют, не спорю. Но давайте взглянем на другую сторону генеративного искусства. Ту, где картинки создаются не гигабайтами весов нейронной сети, а несколькими килобайтами JavaScript-кода.

И кстати раз уж речь зашла про красоту в коде: мы как раз запустили «Конкурс красоты кода 2.0». Самое время показать, что даже простые алгоритмы могут создавать нечто впечатляющее. Именно такие работы, где за внешней простотой скрывается математическая элегантность, часто оказываются самыми интересными.

Во фронтенде часто приходится вызывать асинхронные функции одну за другой, а потом отменять всю цепочку. У каждого опытного разработчика есть свои методы. В этой статье я хочу поделиться своим опытом: как прервать выполнение цепочки вызовов изнутри и снаружи, как обрабатывать ошибки, как перестать ждать результат асинхронной функции и как её можно отменить. 

Интересно? Тогда добро пожаловать под кат! 

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

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

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