WebGL существует уже давно, про шейдеры написано немало статей, есть серии уроков. Но в основной массе они слишком сложные для верстальщика. Даже лучше сказать, что они охватывают большие объемы информации, которые скорее нужны разработчику игрового движка, чем верстальщику. Там сразу начинают с построения сложной сцены, камера, свет… На обычном сайте для создания пары эффектов с фотографиями все эти знания избыточны. В результате люди делают очень сложные архитектурные конструкции и пишут длинные-длинные шейдеры ради очень простых по сути действий.

Все это побудило создать введение в те аспекты работы с шейдерами, которые наиболее вероятно пригодятся в работе именно верстальщику для создания различных 2d-эффектов с картинками на сайте. Конечно с поправкой на то, что сами по себе в дизайне интерфейсов они у нас применяются относительно редко. Мы сделаем стартовый шаблон на чистом JS без сторонних библиотек и рассмотрим идеи создания некоторых популярных эффектов, основанных на сдвиге пикселей, которые сложно сделать на SVG, но при этом они легко реализуются с помощью шейдеров.

Несколько недель назад я обнаружил пост "Окисляем Source Maps с Rust и WebAssembly"
распространяющийся по Твиттеру и расказывающий о выигрыше в производительности от замены обычного JavaScript в библиотеке source-map на Rust, скомпилированный в WebAssembly.

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

Так что я скачал библиотеку с GitHub и отправился в небольшое исследование производительности, которое я документирую здесь практически дословно.

В JS API Яндекс.Карт существует возможность создавать различные объекты на карте. Один из их них – многоугольник, с помощью которого можно улучшить интерактивность пользовательской карты: выделить отдельные области или отобразить местоположение неточечного объекта. К примеру, так можно показать план строительства нового квартала или зоны доставки пиццы.

У пользователей API Яндекс.Карт давно появился вопрос о добавлении подписей поверх многоугольников. Люди предлагали хитрые решения, чтобы добавить подпись на объект в нужном месте, скрыть ее, перекрасить и т.п., но такие решения получались сложными и негибкими.

К примеру, к нам пришел отдел исследований Яндекса с просьбой написать удобный инструмент для подписи многоугольников после того, как они сделали несколько исследований на карте мира.


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

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

Привет, Хабр! Представляю вашему вниманию перевод статьи "REST API Best Practices" автора Krishna Srinivasan.

REST становится общим подходом для представления сервисов окружающему миру. Причина его популярности заключается в его простоте, легкости использования, доступе через HTTP и другие. Существует неправильное представление о том, что все данные, доступные через сеть, считаются REST, но это не так. В этой статье я собираюсь объяснить вам некоторые best practices, которые вы должны всегда помнить при реализации собственного REST приложения. Я бы хотел услышать ваш опыт в REST приложениях, поэтому если вы знаете best practies, которые не упомянуты в этой статье, пожалуйста, поделитесь с нами в комментариях.

Disclamer: все best practies основаны на моем личном опыте. Если вы имеете другое мнение, не стесняйтесь отправлять его мне на email, и мы обсудим его.

Здесь представлен список best practices, которые будут обсуждаться в этой статье:

1. Конечные точки в URL – имя существительное, не глагол
2. Множественное число
3. Документация
4. Версия вашего приложения
5. Пагинация
6. Использование SSL
7. HTTP методы
8. Эффективное использование кодов ответов HTTP

Сегодня, в переводе одиннадцатой части серии материалов, посвящённых JavaScript, мы поговорим о подсистемах браузера, ответственных за рендеринг веб-страниц. Они играют ключевую роль в деле преобразования описаний документов, выполненных с помощью HTML и CSS, в то, что мы видим на экране.



Автор материала говорит, что в компании SessionStack приходится уделять рендерингу огромное внимание. В этой статье он поделится советами, касающимися оптимизации веб-страниц с учётом особенностей их визуализации.

Не важно, какой подход применяется при написании тестов: TDD, BDD, или какой-то другой. Юнит- тесты это первичный защитный барьер, который помогает избежать багов. А хорошо описанные кейсы помогут коллегам понять, что происходит в проекте и не наломать дров в коде.

С 2008 года Google ведет проект Oxygen — исследование успешности своих руководителей. В 2018 году работу руководителей оценивали по внутреннему рейтингу и отзывам сотрудников. Оказалось, что команды с хорошими руководителями работают продуктивнее и чувствуют себя счастливыми. Google провели масштабный опрос сотрудников и выяснили, какие 10 качеств отличают сильного руководителя:

В наших публикациях регулярно появляются статьи о CSS. Среди них — материал об истории CSS, рассказ о подборе имён для CSS-сущностей, статья о CSS-стилях для печати, о которых многие забывают. Мы писали о том, как работают CSS-селекторы, сравнивая происходящее с автосалоном, о сравнительно новой технологии CSS Grid Layout, и о том, что CSS — это не чёрная магия. Сегодня предлагаем вашему вниманию перевод материала, который посвящён странностям CSS, о которых, как полагает автор этого материала, мало кто знает.

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

Привет, Хабр! Представляю вашему вниманию перевод статьи "How to be* a compiler — make a compiler with JavaScript" автора Mariko Kosaka.

*Все верно! Быть компилятором — это здорово!

Дело было одним замечательным воскресеным днем в Бушвике, Бруклин. В моем местном книжном магазине я наткнулась на книгу Джона Маэда “Design by Numbers”. Это была пошаговая инструкция по изучению DBN — языка программирования, созданного в конце 90-х в MIT Media Lab для визуального представления концепций компьютерного программирования.

TL;DR – ДА.

Очередная статья нашего израильского коллеги по WebRTC и звонкам между браузерами переведена для Хабра. Мы в Voximplant разрабатываем собственное решение для организации видеоконференций через сервер и можем сказать что да, все именно так. Peer-to-Peer штука хорошая, но работает не во всех случаях. А сделать хорошую видеоконференцию через сервер не так просто, когда к серверу подключается множество разных веб-браузеров и мобильных устройств, каждый со своим подключением к интернет и своей реализацией видеостека. Через некоторое время мы расскажем о внутренностях нашего решения, а сейчас слово передается Цахи Левент-Леви, создателю широко популярного в узких кругах bloggeek.me

Как известно, JavaScript-движок V8 весьма популярен. Он применяется в браузере Google Chrome, на нём основана платформа Node.js. В материале, подготовленном Мэттом Зейнертом, перевод которого мы публикуем сегодня, приведено девять вопросов, посвящённых особенностям того, как V8 работает с памятью. Каждый вопрос содержит фрагмент кода, который нужно проанализировать и найти ответ, наиболее точно описывающий потребление памяти этим кодом или представленными в нём структурами данных. Ответы на вопросы снабжены комментариями.

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

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

В материале, перевод которого мы сегодня публикуем, Джош Мариначчи рассказывает о том, как использовать CSS-grid для проектирования макетов страниц. Речь пойдёт о страницах, которые способны реагировать на воздействия пользователя и на изменение их содержимого, но при этом всегда ведут себя так, как от них ожидается, в частности — при прокрутке их содержимого.

Актуальны ли ещё угрозы XSS? Прошло около 20 лет с тех пор, как Cross Site Scripting (XSS) появился как вид атаки. С тех пор мы получили богатый опыт и знания, защита наших сайтов стала намного сложнее, а многочисленные фреймворки были призваны оберегать нас от ошибок. Но последние данные показывают совсем другую картину: в первых кварталах 2017 года количество сообщений об XSS-атаках и количество найденных уязвимостей выросло в несколько раз.

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

Прототипом статьи является доклад на конференции HolyJS 2017 Moscow. Алексей — фронтенд-тимлид/архитектор в компании EPAM Systems и один из лидеров сообщества FrontSpot в Минске. Основные области профессиональных интересов: архитектура и инфраструктура приложений, управление разработкой.

В этом тексте огромное количество картинок со слайдов. Осторожно, трафик!

Этим летом я прочитал книгу Илона Маска Tesla, SpaceX, and the Quest for a Fantastic Future. Замечательное чтиво и подробный рассказа о взлётах и падениях одного из крупнейших визионеров нашего времени. Также книга позволила ознакомиться с рабочей этикой Маска и секретами продуктивности, которыми он пользуется для управления несколькими компаниями.

Дизайн сложности

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

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



С открытием каждого технологического новшества наши предметы обихода становились всё более оснащёнными и значительно более сложными. Дизайнеры и инженеры попросту обременяли пользователей подобным увеличением сложности. Мне всё еще снятся кошмары о попытках получить билет на поезд с помощью старого торгового автомата BART в Сан-Франциско.

От сложного к простоте

Сколько себя помню, я всегда был одержим интерфейсами пользователя (UI). Помню, как наслаждался красотой Compaq TabWorks, пока играл в «The Incredible Machine» и слушал «Tears For Fears—Greatest Hits» на семейном компьютере.


Не осуждайте меня — я слушал «Mad World» ещё задолго до выхода «Донни Дарко» и этого страшного кролика. Если вы не узнали ни одну из этих отсылок, то возможно это потому, что я очень стар. Как сказал Джордж Костанза, «Дело не в тебе, а во мне».

Это ещё одна древняя цитата, которую вы можете и не понять. Ну да ладно, давайте двигаться дальше.

По-настоящему я увлёкся UI, когда купил собственный компьютер. Я вступил в береговую охрану и сэкономил немного денег во время курса молодого бойца (когда нельзя было выходить в город из-за отжиманий и всего такого). Я хотел купить Chevy Cavalier (увы, но это не шутка), но мой отец предложил вместо этого потратить деньги на компьютер, поэтому я приобрёл в Office Depot собственный Compaq с Windows 98 в комплекте. Кроме того, Cavalier никак не купить за 800 баксов.

Windows 98

Я провёл кучу времени за изменением тем Windows 98. Я был заворожён тем, как могут накладываться друг на друга окна и как меняются иконки и шрифты, формы кнопок и цвета. Мне нравилось, как окна отбрасывали тень. Каждая новая тема была лучше предыдущей!


О, глубины моря! О, величественные рыбы! ДУХ ЗАХВАТЫВАЕТ.

Если бы я знал, с какими чудесами мне ещё предстоит встретиться. Если бы я только знал о Windows XP.

Многие из проектов на языке С, существующих сегодня, начинали разрабатываться ещё десятилетия назад. Операционная система UNIX стартовала 1969 году (и писалась на ассемблере), но уже в 1972 была переписана на С. Точнее, это язык С был создан для того, чтобы появилось что-то, на что было бы удобно переписать с ассемблера ядро UNIX и получить чуть более высокоуровневый код, менее зависимый от архитектуры и позволяющий выполнять больше полезной работы на каждую строчку написанного кода.

Разработка базы данных Oracle началась в 1977 году (тоже на ассемблере) и тоже была переписана на С в 1983 году. К тому времени это был уже один из самых популярных языков в мире.

В 1985 году вышла Windows 1.0. Хотя код операционной системы Windows не является открытым, общеизвестно, что ядро в основном написано на С с небольшими вставками ассемблера. Разработка Linux началась в 1991 году и началась сразу на С. В следующем году она была опубликована под лицензией GPL и использована как часть GNU Operating System, которая и сама начиналась как проект на С и Lisp, так что многие компоненты были написаны на С.

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

Как именно язык С управляет миром?

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



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

«Netflix хороши в DevOps. Netflix делают микросервисы. Таким образом, если я делаю микросервисы, я хорош в DevOps».

Я всегда был фанатом багов и уязвимостей «на поверхности», всегда завидовал чувакам, которые пишут эксплойты для самых защищённых ОС, а сам умел только скрипткиддить (термин из нулевых). Однако мой пост про уязвимости в системах контроля версий набрал более 1000 лайков на Хабре и остаётся топ1 постом за всю историю Хабра, несмотря на то, что был написан 9(!) лет назад.

И сегодня я хотел бы на пальцах показать и рассказать про такую штуку, как вардрайвинг. А точнее, как стандартными средствами MacOS можно добыть пароли от Wi-Fi соседей. Нелёгкая забросила меня на очередную квартиру. Как-то исторически сложилось, что я ленивый. Пару лет назад я уже писал, что моя лень, новая квартира и провод Beeline (бывшая Corbina) помогли мне найти багу у Билайна и иметь бесплатно интернет в их сети. «Сегодня» происходит «подобное», я на новой квартире, нет даже провода, но есть много сетей у соседей.


Заколебавшись расходовать мобильный трафик, я решил, что «соседям надо помогать», и под «соседями» я имел введу себя…