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

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

Добро пожаловать  на 1-й день челленджа #30DaysOfPlaywright!

Сегодня наша  цель – изучить руководство по началу работы с фреймворком, которое должно помочь настроить средство запуска Playwright Test в локальной среде разработки и подготовить его для  выполнения первого тестового прогона.

Подробный разбор фулфилмент-архитектуры компании Uber.

Как описано в [1], фулфилмент-сервис должен “получить намерение клиента и воплотить его путем подбора правильного набора провайдеров (исполнителей)”. Например, одно из возможных намерений клиента - это поездка из одной точки в другую, а провайдером в этом случае будет являться свободный водитель такси, находящийся как можно ближе к клиенту. Конечная цель фулфилмент-сервиса - это эффективный поиск свободных водителей рядом с клиентом.

Всем привет! В прошлом посте мы с вами разобрали механизмы создания библиотек с помощью Angular libs, а также научились настраивать их работу в приложении и друг с другом и даже вынесли наши ассеты в одну из таких библиотек.

В этом посте хочу продолжить тему разделения функционала на библиотеки и, как апофеоз, рассказать о сборке двух, похожих визуально, но разных по функциональности приложений из одного набора библиотек. А так же осветить механизм работы tree shaking при использовании Angular Libs.

Helm — один из самых популярных пакетных менеджеров для Kubernetes, так что познакомиться с ним поближе стоит всем, кто сталкивается с задачами деплоя приложений. Эта статья завершает мое краткое, но достаточно полное введение в Helm.

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

Присоединяйтесь к #30DaysOfPlaywright. Давайте изучим инструменты, API и лучшие практики, по одному сценарию тестирования за раз!

Вы ещё не слышали, как профессор Гарвардской школы бизнеса «наживается» на своих студентах? Тогда вам, наверное, будет интересно узнать о том, как продать 20 долларов за гораздо большую сумму. Скажем, долларов за 200.

Профессор Макс Базерман придумал эксперимент, который демонстрирует необъяснимое иррациональное поведение будущих профессиональных бизнесменов и менеджеров в их родной стихии — управлении проектами. Кстати, в эту же ловушку попадают и топ-менеджеры крупных компаний, с которыми профессор проводит свои семинары.

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

Хочу поделиться с вами заметками о Docker.

Заметки состоят из 4 частей: 2 теоретических и 2 практических.

Если быть более конкретным:

• эта часть посвящена самому Docker, Docker CLI и Dockerfile;
• в второй части рассказывается о Docker Compose;
• в третьей части мы разработаем приложение, состоящее из 3 сервисов (клиента, админки и API) и базы данных (PostgreSQL);
• в четвертой части мы это приложение "контейнеризуем".

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

Интернет завален статьями «как войти в IT и начать писать код», но куда реже говорят о том, как перестать его писать. Что делать, если больше не хочется весь день смотреть в IDE, но и в тимлиды не тянет? Конечно, можно освоить свиноводство, но есть ли сферы, где пригодится уже полученный опыт? Куда можно свернуть «в сторону» от разработки, и какие скиллы для этого понадобятся?

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

• DevRel: Барух Садогурский
• Экспертная роль: Евгений Борисов
• Стык IT с другой предметной областью: Дмитрий Нестерук
• Собственная компания: Алексей Федоров

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

В основе этого списка — мой личный опыт, и чтобы избежать предвзятости, я расскажу и об альтернативных инструментах, чтобы вы могли всё сравнить и принять решение, исходя из своих потребностей. Постараюсь дать информацию сжато и привести источники, чтобы при желании вы могли изучить всё самостоятельно. Описывая инструменты для различных задач разработки ПО, я хотел ответить на вопрос: «Как я могу сделать X в Kubernetes?»

До HolyJS осталось меньше месяца — пора поведать Хабру, какие именно доклады там будут. Под катом их описания, а тут отметим пару вещей:

— В этот раз шире обычного раскрыта тема производительности. Когда React.memo не ускорит, а замедлит? Почему Solid.JS такой быстрый? Что нужно знать JS-разработчику в современном многоядерном мире?

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

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

Видео — это сложно.

Мы перевели все конференции в онлайн ещё полтора года назад. И все эти полтора года мы мучаемся с плеерами, кодеками, раздачей видео, WebRTC-звонками, транскодингом и ворохом других проблем. Конца и края этому не видно.

А поскольку разбираться в видео нам надо, а фантазия у нас давно закончилась, то мы нашли единомышленников и сделали конференцию VideoTech по видео и стримингу. Она пройдёт в онлайне уже совсем скоро — с 1 по 3 декабря.

В числе основных тем VideoTech 2021 — WebRTC, кодеки видео/аудио, качество видео и его раздача, ML/AI и не только. Полный список тем и докладов — в тексте ниже.

• Андрей рассказал историю развития Playwright и Puppeteer;
• ответил на вопросы про протоколы, которые используют для работы с браузерами;
• рассказал про сложности браузерных движков и планируемые интеграции Playwright.

Перевод статьи Alister Scott: Five reasons why Playwright is better than Cypress

На основании проведенного сравнения, могу смело рассказать о причинах, почему Cypress все еще проигрывает конкуренцию.

Подробности о том, как происходит рендеринг в React и как влияет на рендеринг применение контекста.

Я часто сталкиваюсь с недопониманием относительно того, как, почему и когда React повторно рендерит компоненты и каким образом применение контекста и React-Redux влияет на время и объем повторного рендеринга. С десяток раз понабивав на клавиатуре различные вариации ответов на эти вопросы, я подумал, что имеет смысл составить одно общее пояснение и при каждом удобном случае ссылаться на него. Учтите, что вся собранная здесь информация уже гуляет по сети и рассматривалась в ряде других замечательных статей и публикаций в блогах. Некоторые из них перечислены в качестве справки в конце оригинальной публикации, в разделе Further Information. Собрать разрозненные сведения в единую картину бывает нелегко, поэтому я надеюсь, что моя статья поможет кому-то разобраться в теме.

Только ES2021 (или ES12) был зарелижен этим летом, как многие члены сообщества уже начали заглядывать в будущее, размышляя, в частности, о том, какие новые фичи принесет нам ES2022.

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

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

Допустим, перед вами стоит задача написать фронтенд-приложение. Есть ТЗ с описанием функционала, тикеты в баг-трекере. Но выбор конкретной архитектуры лежит на вас.

Порой трудно заранее понять, какая архитектура будет удачной, а какая нет. Особую сложность представляет организация управления состоянием. Как лучше всего хранить и синхронизировать данные, которые нужно отображать? Каждый по-своему подходит к решению этой проблемы и либо пишет весь код сам, либо берет готовую библиотеку. Любой из этих способов — со своими плюсами и минусами.

В статье я расскажу о своем решении проблемы управления состоянием на примере разных стадий развития приложения.