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

Практически каждая современная графическая сцена являет собой результат работы некоторого кода, написанного специально для GPU — от реалистичных эффектов освещения в новейших ААА-играх до 2D-эффектов и симуляции жидкости.


Сцена в Minecraft до и после применения нескольких шейдеров.

Цель этой инструкции

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

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

Главный минус самостоятельной разработки UI-компонентов — большие затраты сил и времени. Вкладывать ресурсы в подобное дело стоит лишь в том случае, когда речь идёт о чём-то совершенно уникальном. Когда же всё, что нужно — это простые, стандартные элементы, в ход идут библиотеки и фреймворки для разработки пользовательских интерфейсов. Они упрощают и ускоряют работу. Для интеграции в проект элементов управления из подобных «сборников» нужна лишь их настройка — процедура обычно куда более простая, чем разработка собственных компонентов.

Прошло три месяца после JavaScript-конференции HolyJS 2016 Moscow, и это значит, что сейчас самое время выложить видеозаписи докладов и составить рейтинг лучших. Напомню, что рейтинг составляется не «экспертным жюри», а участниками в форме обратной связи – более 400 человек ответили на наши вопросы и поставили оценки докладам, которые они слушали.

В этот раз топ подобрался интересный, разнообразный и почти полностью англоязычный. Вы найдете видео о (dev)tools и ServiceWorker'ах, о минимизации кода и роли UX в обойме навыков frontend-разработчика и о многом другом, включая WebVR.

Разнообразие зоопарка инструментов в мире JS не обошло стороной и HolyJS — почти каждый доклад в той или иной степени посвящен какому-либо фреймворку или инструменту, — но обзор для каждого из них дан глубокий и исчерпывающий, не заскучаете.

Продолжение перевода статьи A Brief History of JavaScript, подготовленный отделом фронтенд-разработки компании Лайв Тайпинг. Первая часть закончилась на том, что в ноябре 1996 года язык JavaScript начали приводить к стандартам ECMA. С этих пор язык проходит по бумагам как ECMAScript, но в обыденной жизни все называют его по-прежнему. Читайте во второй части: версии ECMAScript, появление технологии AJAX, ActionScript и его влияние на Flash и путь к Гармонии.

Краткая история JavaScript. Часть 1

Хочу рассказать простой способ создания слайдера, без использования JS, при помощи анимации CSS.

1) Для начала напишем HTML, предположим что в слайдере будут сменять друг друга 4 изображения.

  <div class="slider">
      <div class="slide slide1"></div>
      <div class="slide slide2"></div>
      <div class="slide slide3"></div>
      <div class="slide slide4"></div>
 </div>

Писать об этом очень тяжело, даже тяжелее, чем признаться себе в этом. Я писал заявления об увольнении с любимых мест работы, заканчивал отношения, много в чем не преуспел и портил свою репутацию. Но чувства, которые я из-за этого испытывал, были временными: поначалу бывало очень плохо, но через пару месяцев я оставлял это позади и жил дальше. И все же есть одно чувство, от которого мне так и не удалось избавиться за всю свою карьеру: синдром самозванца.

Переведено в Alconost

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

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

Не будем лукавить: JavaScript никогда не был идеальным языком программирования. Одним из слабых мест в JS была модульность, а точнее её отсутствие. Действительно, зачем в скриптовом языке, который анимирует падающие на странице снежинки и валидирует форму, заботиться об изоляции кода и зависимостях? Ведь всё может прекрасно жить и общаться между собой в одной глобальной области — window.

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

Эта статья появилась в результате общения с участниками TC39 и разработчиками фреймворков, а также чтения исходных кодов, блогов и книг. Мы рассмотрим следующие подходы/форматы: Namespace, Module, Detached Dependency Definitions, Sandbox, Dependency Injection, CommonJS, AMD, UMD, Labeled Modules, YModules и ES2015 Modules. Кроме того, мы восстановим исторический контекст их появления и развития.

Коллекционная карточная игра Hearthstone: Heroes of Warcraft — популярное онлайн-развлечение и одна из крупных киберспортивных дисциплин. В новом посте «Менеджмент игровых интернет-проектов» мы публикуем перевод статьи гейм-дизайнера Ubisoft Станислава Костюка о роли разных типов случайностей в этой игре и об их эмоциональном воздействии на игроков.

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

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

Я сейчас не говорю про «Административный кодекс», куда я как раз и отношу неправильное применение шаблонов, неиспользование тестов, неоптимизированный код, даже харкодинг каких-нибудь настроек и «магические числа» (хотя уже на грани). В этих случаях разная правоприменительная практика. Например оптимизированный код часто сложнее для понимания, чем неоптимизированный. Неоптимальный алгоритм зачастую легче воспринимается при чтении кода, а ведь разработчик 95% времени читает свой или чужой код и только 5% пишет. Или если вы пишите скрипт для друга забесплатно, побыстрее и заходкодили пару настроек, вы скорее всего правильно поступили. Решив, что интеграция туда логики извлечения настроек (и ее тестирования) из отдельных конфигов потребует намного большего времени, чем хардкод.

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

Данная стать является переводом вот этой статьи. В ней я расскажу вам как удобно использовать Vue.js фреймворк при разработке приложения на ASP.NET MVC

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

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

Хотя JavaScript поддерживает методики функционального программирования, он не оптимизирован для полноценного использования этой парадигмы, как Haskell или Scala. Не обязательно добиваться того, чтобы ваши JS-программы полностью соответствовали концепциям функционального программирования. Но их применение помогает поддерживать чистоту кода и концентрироваться на создании архитектуры, которая легко тестируется и может использоваться в нескольких проектах.

Насколько сложно построить полноценный сервис email-маркетинга? Что для этого нужно предусмотреть? Какие подводные камни могут встретиться на пути пытливых умов разработчиков?



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

Сразу оговорюсь, что в статье рассмотрена только техническая сторона вопроса.

В современном веб-дизайне существует достаточно много инструментов для web-дизайна. Это и классика — графические редакторы Photoshop и Sketch, и программы, совмещающие одновременно дизайн и верстку, такие как Macaw и Adobe Muse. И, как мы считаем, будущее web-дизайна — платформы для визуального дизайна сайтов в браузере, одним из примеров которых является Pixli.

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

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

Я хочу рассказать о процессе создание платформы для react приложения, которая использует mobx в качестве Model-и. Пройти путь от пустой директории проекта до рабочего примера. Рассмотреть основные моменты, на которые я обращал внимание в процессе разработки. Постараюсь насытить текст уточняющими ссылками, дополнительные заметки будут выделены курсивом с пометкой «Note:».

Рассказ будет состоять из двух частей:

1. Готовим плацдарм для react приложения
2. Mobx + react, взгляд со стороны

Буду писать «как я вижу», поэтому предложения и замечания по улучшению приветствуются. Надеюсь, читатель знает, что такое npm, node.js и react.js, имеет базовые знания о props и state. На момент написания статьи, у меня стоит windows и нестабильная node.js 7.3.0 версии.

Отдел фронтенд-разработки компании Лайв Тайпинг перевёл для читателей Хабра большой материал о зарождении, развитии и перспективах языка JavaScript, вышедший в блоге сервиса Auth0. Сегодня мы публикуем первую часть перевода. Соперничество Netscape и Mosaic, грёзы об интерактивном вебе, язык программирования для не-программистов, переход от классов к прототипам и что общего между JavaScript и ECMAScript (спойлер: всё).

Краткая история JavaScript. Часть 2
Краткая история JavaScript. Часть 3

Обычно при веб-разработке на всех уровнях стека используются разные языки программирования. База данных MongoDB, фреймворки Express и AngularJS и технология Node.js вместе образуют стек MEAN — мощную платформу, на всех уровнях которой применяется всего один язык: JavaScript. Стек MEAN привлекателен для разработчиков и бизнеса благодаря простоте и экономичности, а конечные пользователи любят MEAN-приложения за их скорость и отзывчивость.

JavaScript достиг зрелости. Благодаря ему теперь можно создать веб-приложение от начала до конца с помощью всего одного языка программирования. Стек MEAN включает в себя лучшие в своем классе технологии в данной области. В качестве БД вы получаете MongoDB, в качестве серверного фреймворка веб-приложений — Express, в качестве клиентского фреймворка — AngularJS, а в качестве серверной платформы — Node.

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

Недавно мы писали статью о том, как сделать расширение скриншаринга для браузера Google Chrome. В результате мы создали собственное расширение для скриншаринга, опубликовали его в Chrome Store и протестировали трансляцию экрана через Web Call Server в режиме один-ко-многим.

В этой статье мы проделаем тоже самое с браузером Firefox. Подход остается прежним и снова потребуется упаковка и публикация расширения, на этот раз в Mozilla Add-ons. В результате мы сможем делать скринкасты видеопотоков из FF без установки внешнего дополнительного ПО.

Наверняка видели десятки лендингов с заголовками секций в виде «Как мы работаем», «Чем мы лучше других», «Этапы работы», «Наши выгоды», «О нас», «О компании» и т.д. Без слез не взглянешь. Такие заголовки абсолютно не работают. Потому что вы пишите не оглавление книги для чтения, а текст, с помощью которого хотите продать продукт своим потенциальным клиентам. Для этого нужно использовать различные схемы и методики, которыми мы хотим поделиться.

Предлагаем вашему вниманию перевод статьи, посвящённой рассмотрению используемых в программировании моделей памяти.

Сегодня в программировании доминируют шесть основных моделей памяти (не путать с моделями памяти Intel 8086). Три из них проистекают из трех исторически наиболее важных языков программирования 1950-х годов — COBOL, LISP и FORTRAN, а остальные связаны с тремя исторически важными системами хранения данных: магнитная лента, иерархическая файловая система в Unix-стиле и реляционная база данных.

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