История развития IT намного интереснее любой мыльной оперы, но пересказывать ее мы не будем. Скажем только, что были свидетили принципа «data-driven», адреналинщики с two-way-binding и беспредельщики без принципов и понятий.

Бог создал людей сильными и слабыми. Сэмюэл Кольт сделал их равными.
Примерно тоже самое сделали Flux и Redux.

Была только одна проблема — Redux по сути своей крайне примитивная хреновина, и чтобы с ним хоть как-то работать надо было добавить парочку middleware — thunk, saga, observable и так далее.

Но эта статья заходит с другой стороны, серьезно так спрашивая про композицию, и, в частности, про компонентную модель. Которой в редаксе — нет.

Когда нужно сделать несколько запросов к HTTP API, разработчик обычно берет свой привычный язык/фреймворк и быстро пишет аналог curl в коде: HTTP-запрос, минимальный контроль ошибок, query- или json-аргументы, парсинг json body с названиями полей в виде строк. Все это замечательно работает, пока проект не начинает расти и несколько вызовов не превращаются в несколько десятков, а куски низкоуровневого кода не начинают размножаться копипастой. А дальше — стандартный набор багов, рожденных копипастой, которые начинают понемногу есть время у разработчика.

Swagger/OpenAPI — один из «комбайнов» для работы с HTTP API. Это язык описания API (недавно произошло объединение проектов генератора и спеки), генераторы серверного и клиентского кода, документации, тестов — много всяких полезных штук. Под катом я покажу, как по «человеческому» описанию API на сайте компании в несколько строк кода составить OpenAPI-описание и сгенерировать клиент на Python. И чем такой клиент будет лучше, чем вручную написанный код.

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



Библиотека React, созданная Facebook, представляет собой мощный JavaScript-фреймворк, упрощающий работу программистов, занимающихся веб-разработкой. Однако, если вы работали какое-то время с React JS, вы согласитесь с тем, что для того, чтобы в полной мере раскрыть возможности этого фреймворка, не помешает ещё несколько дополнительных библиотек.

Автор материала, перевод которого мы сегодня публикуем, говорит о том, что из опыта знает о важности опенсорсных проектов в деле веб-разработки. Однако, из-за того, что на GitHub присутствует очень много библиотек для React, программисты оказываются избалованы выбором. Поэтому было бы неплохо сузить рассматриваемые варианты до буквально нескольких проектов. Перед вами — обзор первой десятки самых популярных библиотек для React с GitHub, ранжированных по количеству присвоенных им звёзд.

Я хотел бы рассказать вам о своем опыте в разработке инди игры. Мой опыт ограничен всего одной игрой, которая на данный момент находится в “раннем доступе” в Steam. Это не много, но мне кажется мне есть чем поделиться. Если не хочется читать все — в конце самое интересное кратко.

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

К сожалению, эта простота имеет свою цену: низкую производительность. Несмотря на то, что существует множество способов оптимизации и параллелизации трассировщиков лучей, они всё равно остаются слишком затратными с точки зрения вычислений для выполнения в реальном времени; и хотя оборудование продолжает развиваться и становится быстрее с каждым годом, в некоторых областях применения необходимы красивые, но в сотни раз быстрее создаваемые изображения уже сегодня. Из всех этих областей применения самыми требовательными являются игры: мы ожидаем рендеринга отличной картинки с частотой не менее 60 кадров в секунду. Трассировщики лучей просто с этим не справятся.

Тогда как это удаётся играм?

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

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

В этой работе мы сосредоточимся не на скорости, а на чётком объяснении концепций. Код примеров написан наиболее понятным образом, который не обязательно является самым эффективным для реализации алгоритмов. Есть множество способов реализации, я выбрал тот, который проще всего понять.

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

Время чтения: 13 минут

Много ли вы видели react разработчиков, которые покрывают свой код тестами? А вы-то тестируете свои? Действительно, зачем, если мы можем предсказать состояние компонента и стора? Ответ довольно прост: чтобы избежать ошибок при изменениях в проекте.

Всех, кого заинтересовало, приглашаю под кат.

Эта статья основана на моём выступлении на ITSubbotnik, прошедшем в Рязани 14 октября 2017 года. На русском пока что довольно мало материала на эту тему, надеюсь что статья будет вам полезна.

Disclaimer: Автор не является экспертом ни в WebAssembly, ни в JavaScript. Данная статья есть компиляция мыслей и идей, полученных из выступлений других людей на данную тему, плюс эпизодического опыта изучения WebAssembly в течение нескольких месяцев.

Фабрика виджетов — способ организации клиентского кода, который отлично вписывается в архитектуру multi-page application (MPA).

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

Виджетами будут называться компоненты (или контейнеры компонентов), точкой инициализации которых будет DOM. И в которые можно будет передать данные из шаблона.

А сейчас обо всем последовательно.

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

DI как основа для построения фреймворка, применительно к вебу, довольно молодой подход. Что бы тут было понятней о чем идет речь, начну c привычных для react-разработчиков вещей.

Фрактальные истории, или как создать текстовую адвенчуру с открытым миром

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

Моя идея превратилась в короткую игру Insignificant Little Vermin, с которой я участвовал в этом году на IFCOMP. В статье я расскажу о процессе создания этой игры и о том, чему я научился, понаблюдав за тем, как в неё играют люди (на Twitch).

Уважаемые коллеги, представляю вашему вниманию и на ваше осуждение контейнер для управления состоянием React приложения xstore. Он определенно является таким маленьким детским велосипедом рядом с большим и сверкающим мотоциклом Redux. Все мы программисты JavaScript являемся такой большой и не сбавляющей обороты фабрикой по производству велосипедов.

Для более менее просто начинающих или начинающих свое знакомство с React JavaScript программистов Redux может показаться несколько сложной штукой, которая иногда непонятно как работает и к которой сложно "законнектиться", хочется чего-то попроще, чего-то похожего на данный маленький велосипед.

Давайте рассмотрим его поближе.

Установка

npm install --save xstore

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

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

Как-то для своих некоторых планов мне потребовалось сделать небольшую песочницу в 2D пространстве с базовыми возможностями:

1. Передвижение по игровому миру
2. Физика при движении, столкновения
3. Создание блоков
4. Удаление блоков

Графическое исполнение меня не беспокоило, поэтому я решил оформить все в серых тонах, выглядит это так:

Цель данной статьи — вместе с читателем написать окружение для разработки современных веб-приложений, последовательно добавляя и настраивая необходимые инструменты и библиотеки. По аналогии с многочисленными starter-kit / boilerplate репозиториями, но наш, собственный.

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

2017-10-30 16:43. Disclaimer: Данный анализ проведён исходя из модели поведения пользователя использующего специализированные сайты-фотохостинги. В случае универсальных ФАЙЛОхостингов и соцсетей у пользователя другая модель поведения и про это будут отдельные исследования.



В прошлый раз я описал явление и ввёл термин "цифровой износ", а на следующее, после публикации, утро обнаружил что в тот же день на mobile-review вышел обзор с упоминанием подобной темы. В обзоре рассказывалась история про человека который несколько лет загружал свои фотографии в Google Photo и в итоге лишился исходников.

«Это знак», — подумал я и решил провести анализ популярных фотохостингов на предмет цифрового износа фотографий.

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

Условия эксперимента: пользователь поехал на публичное мероприятие (в моём случае — всероссийский чемпионат «Лесоруб-2017»), по возвращении домой закинул фотографии в интернет (с помощью браузера) и потом пробабал исходники. Пробабал самым обычным образом — диск покрашился, случайно стёр папку, сознательно чистил диск будучи уверенным что у него в интернете всё сохранено и т.п. И потом, время спустя, пользователь понял что оригинала у него нет и пошёл скачивать то что у него «в интернете».

Но он забыл, что любые сервисы в любой момент могут пропустить ваши фотографии через мясорубку или вообще закрыться.

Посмотрим, что было в начале, что осталось в конце и насколько велик износ.

Поехали!

Цель данной статьи — вместе с читателем написать окружение для разработки современных веб-приложений, последовательно добавляя и настраивая необходимые инструменты и библиотеки. По аналогии с многочисленными starter-kit / boilerplate репозиториями, но наш, собственный.

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

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

Это перевод поста из официального блога JS-движка V8. Статья короткая, текста мало, больше похоже на увлекательный рассказ о проблемах, подстерегающих ни о чём не подозревающих сотрудников Google в коде V8. Речь пойдёт об ускорении обработки ES6 Прокси в V8, которое будет доступно в Chrome 62 и Node v9.x, и совсем немного о том, как лучше применять прокси для получения максимальной скорости работы.

Введение

Прокси появились в JavaScript с принятием стандарта ES2015. Они позволяют перехватывать фундаментальные операции объектов и переопределять их поведение. Прокси являются основой таких библиотек, как jsdom или Complink RPC library. В последнее время мы приложили много усилий, чтобы улучшить производительность прокси в V8. Эта статья проливает немного света на общие подходы к улучшению производительности в V8 и для прокси в частности.

Термин "модуль" (module) взят из статьи Modules vs. microservices. Так же для описания чего-то среднего между микросервисами и монолитами иногда используют термины "микролит" (microlith) или "моносервис" (monoservice). Но, не смотря на то, что термин "модуль" и так уже нагружен общеизвестным смыслом, на мой взгляд он подходит лучше других вариантов. Update: В комментарии lega использовал термин "встроенный микросервис" — он лучше описывает суть подхода, чем "модуль".

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

Я пишу микросервисы с 2009 года, но применять модули вместо микросервисов в реальных проектах пока не пробовал — всё описанное далее это моё предположение о том, каким должен быть вышеупомянутый баланс, и оно нуждается как в теоретической критике так и в проверке практикой.

Рано или поздно у каждого кто работал с webworkers возникает ситуация когда код превращается в кашу вроде этого:


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

Цели:

— Читаемость кода
— Конкурентные запросы
— Ассинхронные функции
— Прозрачная обработка ошибок
— Возможность отправки промежуточных результатов выполнения процедуры