Люди продолжают утверждать, что современные объектно-ориентированные языки, на самом деле "не совсем объектно-ориентированные", поскольку они не соответствуют определению ООП Алана Кэя. На мой взгляд, в этом есть смысл, хотя я и не согласен с выводом. В последнее время мне встречаются люди, которые говорят о том, что именно Кэй изобрёл объекты. Фактически это неверно.

Алан Кэй не изобретал объекты. Они были в Simula, которую приводит в качестве основного источника вдохновения руководство к Smalltalk-72 (с. 117). В выпуске известного журнала Byte за 1981 год, который популяризировал Smalltalk и ООП, говорится, что "основная идея объектов, сообщений и классов пришла из SIMULA". В нем сказано, что Simula позволяет пользователям создавать "объектно-ориентированные системы", что, возможно, слишком, но тем не менее. Команда Smalltalk хорошо знала систему объектов в Simula и черпала вдохновение из неё.

Одной из причин, почему такой миф всё ещё жив, послужило то, что сказал сам Кэй в 1998 году:

Просто напоминаю, что на последней OOPSLA я постарался донести до всех, что Smalltalk — это не только НЕ синтаксис или библиотека классов, но даже не классы. Мне очень жаль, что ранее я ввел термин "объекты" для этой темы, поскольку это заставляет многих людей сосредоточиться на меньшей идее.

• подключение di для компонентов
• серверный рендеринг с асинхронной загрузкой данных

В своей прошлой статье я рассуждал о том, как использование паттерна MVVM позволяет упростить процесс разработки. Паттерн был реализован с применением библиотеки MobX. Эту библиотеку я считаю в разы удобнее Redux, аргументы в пользу чего я также привел в статье. Однако, у нее имеется серьезный недостаток - излишняя свобода действий, в следствие наличия которой разработчики не всегда знают как писать код "хорошо". Паттерн MVVM же диктует несколько простых правил по использованию MobX, благодаря которым разработчики могут реже наступать на грабли. Однако, он не решает всех проблем. И в этой статье я бы хотел показать, как можно дополнить паттерн MVVM и сделать процесс разработки ещё приятнее.

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

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

Если мы что-то и знаем о курильщиках, так это то, что пугать их вредом курения трудно, а главное — бессмысленно. Самые красноречивые картинки на сигаретных пачках в лучшем случае оставят курильщика равнодушным. В худшем — он немедленно зажжёт ещё одну сигарету, чтобы снять стресс.

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

Я бросил себе вызов: симулировать 1000000 (миллион) частиц на чистом Javascript на телефоне, используя только CPU и добившись 60 FPS.

Поехали.

Задача не особо сложна, если выполнять всю работу на GPU, но правило гласит, что нужно пользоваться только CPU, при этом работая на JS, так что никакого WASM.

Когда ручного тестировщика впервые просишь проверить метод REST API, того охватывает паника: «Как это делать? Я вообще почти ничего не знаю про API. Что делать? Как это тестировать?»

Спокойно. Без паники =) Я уже рассказывала на простом языке, что такое API. А сегодня я расскажу о том, как его тестировать. На самом деле почти также, как GUI: в первую очередь это тест-дизайн и придумывание проверок, а потом уже всякие API-штучки. Но и про них не стоит забывать.

Я дам вам чек-лист, к которому вы сможете обращаться потом — «так, это проверил, и это, и это. А вот это забыл, пойду посмотрю!». А потом мы обсудим каждый пункт — зачем это проверять и как.

После теории будет практика! Для неё возьмем метод doRegister системы Users — он находится в открытом доступе, можете дергать по ходу чтения и проверять =) 

Недавно я в очередной раз столкнулся с типичной проблемой: для создания нового функционала фронтенд и бэкенд нужно было реализовывать параллельно. Но как делать фронт, не имея 100% рабочих эндпойнтов на бэкенде? Сегодня я расскажу о том, какие подходы применял, и разберу их плюсы и минусы.

Всем привет! Сегодня я хочу рассказать о Mock Service Worker — технологии, которая позволяет эмулировать поведение бэкенда в ситуациях, когда по каким-то причинам невозможно использовать реальный бэкенд для полноценной разработки фронтенда, а также когда необходимо изолированно протестировать различные пользовательские сценарии. Тем более, что совсем недавно вышла новая мажорная версия библиотеки msw, и в ней достаточно много важных обновлений.

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

Однако консультант по юзабилити Стив Круг, автор книги «Не заставляйте меня думать. Веб-юзабилити и здравый смысл» пришел к выводу, что важно даже не само количество кликов, а их сложность, и вот что это значит.

Пользователи не возражают против большого числа кликов, если каждый клик является «безболезненным» и поддерживает их уверенность в том, что они на верном пути — идут вслед за тем, что часто называют «запахом информации». Термин взят из исследования Питера Пиролли и Стюарта Карда на тему «следование за информацией» научно-исследовательского центра Xerox PARC, в котором они проводят параллели между людьми, отыскивающими информацию, и животными, следующими за запахом своей добычи. 

Ссылки, которые ясно и недвусмысленно указывают на свои цели, источают стойкий «запах», вселяющий в пользователей уверенность, что щелчок мышью приведет их ближе к «добыче». Двусмысленные ссылки или ссылки с плохо подобранными словами подобным образом на людей не действуют. 

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

Вот пример старого веб-дизайна онлайн-статьи на ресурсе издания с трудным неоднозначным выбором для пользователя: 

Привет, друзья!

В данном туториале я покажу вам, как тестировать компоненты на React с помощью Jest и Testing Library.

Список основных задач, которые мы решим на протяжении туториала:

1. Создание шаблона React-приложения с помощью Vite.
2. Создание компонента для получения приветствия от сервера.
3. Установка и настройка Jest.
4. Установка и настройка Testing Library.
5. Тестирование компонента с помощью Testing Library:
   
   1. Используя стандартные возможности.
   2. С помощью кастомного рендера.
   3. С помощью кастомных запросов.
6. Тестирование компонента с помощью снимков Jest.

Репозиторий с кодом проекта.

Если вам это интересно, прошу под кат.

Привет, Хабр!

Тема обработки ошибок в JavaScript возникает не только у каждого новичка, но и матерого разработчика. Замечу, что тема уже довольно заезжена, поэтому я позволю себе резюмировать в кратком изложении все, что действительно эффективно и проверено в бою мною, коллегами и гуру IT.

Как сделать падение мягким?