Привет, Хабр!
В этой статье рассмотрим, почему безобидная строчка await fetch() неожиданно превращается в тормоз, где именно она зарывает драгоценные миллисекунды — и что можно сделать с этим.
После прочтения этой статьи вы хорошо поймете следующее:
Понять, как JS работает "под капотом" в браузере (см. эту короткую 15-минутную статью), проще, чем понять устройство Node.js. В браузере нет сложных фаз и многослойных механизмов, как в Node.js.
Но почему в Node.js все устроено сложнее? Зачем столько фаз, которые так непросто понять?
8 лет назад я исправил опечатку в чужом репозитории, а сейчас регулярно делаю коммиты в проекты, которые использую, и даже вошел в core team библиотеки с 27000 звёзд на GitHub
В этой статье покажу, что участие в Open Source проще, чем кажется. Расскажу, как регулярная работа с чужим кодом помогает быстрее разбираться в незнакомых кодовых базах, писать тесты и лучше документировать решения. А также объясню, почему публичная активность на GitHub выгодно отличает вас от других разработчиков, особенно в эпоху повсеместного использования ИИ.
Что такое TypeScript? Официальная документация отвечает так: “TypeScript — это JavaScript с синтаксисом типов”. Однако некоторые считают TypeScript своеобразным слиянием двух языков: языка для манипулирования значениями JavaScript и языка для манипулирования типами.
Cистема типов TypeScript Тьюринг-полная. Это означает, говоря по-простому, что система может решить любую вычислительную задачу при наличии некоторого представления входных и выходных данных.
Можно ли использовать это знание на практике? Как избежать крайностей от примитивного аннотирования типов до избыточного усложнения?
Эта статья для разработчиков, которые уже используют TypeScript, но хотят выйти за рамки базовых практик. Мы не будем обсуждать синтаксис или настройку конфигураций. Вместо этого сосредоточимся на стратегиях, которые помогут:
В этой статье я хочу поделиться своим опытом настройки WSL для комфортной разработки, а также размышлениями о том, почему такой подход оказался для меня оптимальным. На это влияет несколько факторов.
Во-первых, иногда требуется специфический софт, который доступен только под Windows. Да, в других ОС могут быть аналоги, но зачастую они менее удобны или требуют дополнительной настройки.
Во-вторых, для разных проектов нужно разное окружение. WSL позволяет легко изолировать среды разработки, настраивая их под конкретные задачи или группы проектов. Это гораздо удобнее, чем держать несколько физических машин или постоянно переустанавливать систему.
Наконец, есть и субъективный фактор — привычка. Я с самого начала работал с Windows, и, несмотря на все преимущества Linux, полностью перестроить рабочий процесс оказалось сложно. WSL в этом плане — идеальный компромисс: Linux-окружение под рукой, но без необходимости отказываться от удобств Windows.
Покрытие UI-тестами — вещь, о которой все говорят, но почти никто не измеряет. А если и измеряет, то по старинке, через Excel, TMS или на глаз. Это как считать шаги, не надевая шагомер.
ui-coverage-scenario-tool — это как шагомер, но для UI-тестов. Он показывает, с чем именно взаимодействуют ваши тесты, что осталось в тени, и главное — делает это автоматически. Без ручного труда, без вымышленных цифр, без «по ощущениям».
Это не очередной инструмент ради красивого дашборда. Это инструмент, который ставит зеркало перед вашим UI-покрытием — и показывает, есть ли там что-то, кроме отражения.
Привет, Хабр (и просто случайные читатели, зашедшие сюда в поисках истины или интересной статейки на пару минут)!
Так вышло, что последние полгода я провёл в тесных объятиях «Личного кабинета сотрудника» на Элементе — новом языке программирования от 1С. За это время я успел его изучить, полюбить, возненавидеть, снова полюбить и, наконец, написать эту статью, чтобы поделиться своими впечатлениями, страданиями и неожиданными открытиями.
Привет всем! Меня зовут Антон Галич, я фронтенд-инженер в департаменте разработки Analytics Platform в Авито. В этой статье я рассказываю историю о том, как мы перевели аналитику для внутренних сервисов компании на нашу собственную платформу, отказавшись от стороннего решения Amplitude.
JetBrains зарелизил новую версию своего AI-ассистента и вместе с ним Junie - автономного нейросетевого агента-программиста, которому можно поручать небольшие рабочие задачи.
Буквально вчера я получил к нему доступ и не смог не воспользоваться возможностью. Я даже не представлял...
"JavaScript отстой, потому что '0' == 0!"
Да, эта часть JavaScript действительно ужасна, но сегодня в любом проекте есть линтер, который тут же заворчит на вас за такой код.
Вместо этого я хочу поговорить о более странных особенностях JavaScript — о таких, которые гораздо более коварные, чем эта ☝️ - о вещах, которые вы не найдете ни на r/ProgrammerHumor, ни в обычном учебнике по JavaScript.
Все эти странности могут возникнуть в любом окружении JavaScript/ECMAScript (будь то браузер, Node.js и т.д.), с режимом use strict или без него. (А если вы работаете над легаси-проектами без строгого режима, вам следует срочно подумать о смене работодателя).
Всем привет! Меня зовут Паша и возможно вы уже пользуетесь моим расширением Ave blacklist для блокировки продавцов спамеров на авито. Но сегодня не об этом.
Больше года назад Кабинет министров не поддержал законопроект с ценой за килограмм или литр, новость была на Пикабу в том числе
Что ж, Кабинет министров не поддержал, а я поддерживаю двумя руками!
И написал расширение для браузеров для расчета цена за единицу измерения на сайтах доставок еды - заКило (chrome, firefox)
Мог бы научить и в офлайн магазинах цену за единицу измерения считать, но кто бы меня спрашивал :D
Как превратить скучные слайды в интерактивную демонстрацию, где код можно запускать прямо на месте? В этой статье попробуем перенести презентацию в браузер, а затем — в «блокнот». Интерактивные среды, такие как Jupyter Notebook, Observable, Mathematica, WLJS Notebook, позволяют создавать живые презентации, лекции и наглядные материалы для коллег или студентов. Они незаменимы и для визуализации моделей, симуляций и любых данных.
Под катом — примеры, пошаговый разбор и демо вживую.
WebAssembly являясь (относительно) молодой технологией уже довольно распространён в индустрии.
Тем не менее, почти все материалы в сети по теме рассматривают WASM как цель для компиляции других более высокоуровневых языков.
Информации же по работе с самим WebAssembly и написанию кода непосредственно на нем в сети крайне мало, а в рунете и подавно, что я и попробую исправить под катом.
Асинхронный JavaScript-код встречается практически в любом проекте (самый популярный пример использования — сетевые запросы). Но работа с ним сопряжена с рядом особенностей. Одна из них — специфичная работа с ошибками. Так, поскольку ошибки могут возникать в разное время и в разном месте, надо уметь их отлавливать, определять место «поломки» и корректно передавать всю информацию для последующей обработки. Для этого критически важно, чтобы stack trace ошибки был не формальный «однострочник», а максимально информативный.
