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

WebGL, в отличие от Javascript, имеет высокий порог вхождения, его до сих пор мало кто использует, а ещё меньше тех, кто об этом пишет. Большинство руководств или статей перепрыгивают сразу на использование какой-нибудь библиотеки. Но мы-то с вами знаем, что большие универсальные инструменты не всегда пригодны для наших задач или, возможно, делают это на неприемлемом уровне: проигрывают в скорости, поставляются с ненужным багажом и т.д.

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

PassportJS — это middleware для авторизации под node.js. Passport поддерживает авторизацию с помощью огромного количества сервисов, включая «ВКонтакте» и прочие твиттеры. Список сервисов можно просмотреть здесь. Я хочу немного рассказать о том, как работает этот middleware на примере самой обычной авторизации с помощью логина и пароля.

Для самых нетерпеливых — готовый проект можно посмотреть здесь.

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



Прикладной уровень является самой надежной защитой. Уязвимости, с которыми мы тут встретимся, зачастую полагаются на сложные сценарии ввода данных пользователем, что делает их трудноопределимыми с помощью систем обнаружения вторжений. Этот уровень — самый доступный извне. Для нормального функционирования приложения должен быть доступ через порт 80 (HTTP) или порт 443 (HTTPS).

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

Продолжаем перевод статьи smashingmagazine, в котором подробно рассмотрены все нюансы разработки интерфейсов с помощью flexbox на примере сайта Tracks.

Часть 1

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

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

Часть 2

Моя серия заметок ES6 in Depth, состоящая из 24 записей, описывает большинство синтаксических изменений и нововведений в ES6. В этой публикации я подведу итог всего изложенного в предыдущих статьях, чтобы дать возможность посмотреть еще раз на всё вместе. Также я добавил ссылки на мой блог, чтобы в случае необходимости сразу же можно было посмотреть подробнее.



Я слышал, вы любите маркированные списки, так что вот вам статья со списком, который состоит из нескольких сотен элементов.

Моя серия заметок ES6 in Depth, состоящая из 24 записей, описывает большинство синтаксических изменений и нововведений в ES6. В этой публикации я подведу итог всего изложенного в предыдущих статьях, чтобы дать возможность посмотреть еще раз на всё вместе.

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



В первом случае поиск занимает A?ⁿAⁿ времени, во втором — Aⁿ.

Степени обозначают повторяемость строк, то есть A?³A³ — это то же самое, что и A?A?A?AAA. Графики отражают время, требуемое для поиска через регулярные выражения.

Обратите внимание, что в Perl для поиска строки из 29 символов требуется более 60 секунд. А при втором методе — 20 микросекунд. Это не ошибка. При поиске 29-символьной строки Thompson NFA работает примерно в миллион раз быстрее. Если нужно найти 100-символьную строку, то Thompson NFA справится менее чем за 200 микросекунд, а Perl понадобится более 10¹⁵ лет. Причём он взят лишь для примера, во многих других языках наблюдается та же картина — в Python, PHP, Ruby и т. д. Ниже мы рассмотрим этот вопрос более детально.

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

Возникает логичный вопрос: а почему бы в Perl не использовать метод Thompson NFA? Это возможно и следует делать, и об этом пойдёт далее речь.

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

К окончанию данного руководства вы получите систему из 3 серверов: балансировщик (lb) и 2 сервера приложений (app1 и app2). Балансировщик будет следить за доступностью серверов и распределять между ними траффик. Серверы приложений будут использовать комбинацию systemd и кластеризации node.js для балансировки траффика между несколькими процессами ноды на сервере. Вы сможете выкатывать код с помощью одной команды со своей машины, и при этом не будет перерывов в обслуживании или необработанных запросов.
Все это можно представить в виде схемы:

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

BrowserSync

Я считаю это лучшим Live Reload инструментом. BrowserSync — это: конечно же перезагрузка страницы после изменения исходных файлов в том числе и серверных (PHP, ASP, Rails и др); синхронизация с десктопами, планшетами и смартфонами; синхронизирует между браузерами скроллинг, данные в формах и множество других действий; существует как Grunt и Gulp плагин; доступен на Windows, Linux, MacOS.

npm install -g browser-sync

// Using a an IP based host
browser-sync --proxy "192.167.3.2:8001" --files "app/css/*.css"

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

Мир javascript развивается с невероятной скоростью: новые стандарты языка, новые фреймворки, и в браузере, и на сервере и в десктопных приложениях и так далее… Но иногда хочется вместо изучения новой супер-фичи погрузиться в какую-то более базовую тему. И погрузиться глубоко, до самых исходников.

И в этот момент под моим пристальным взглядом оказалась незаметная строчка «native code», которая так или иначе появляется перед глазами любого JS разработчика в консоли Chrome или Node.js:

[].sort.toString();
"function sort() { [native code] }"

Итак, кому интересно, какая реализация сортировки скрывается в V8 за надписью [native code] — добро пожаловать под кат.

Недавно встала задача сверстать сайт не просто быстро, а очень быстро.

Поэтому было принято решение развернуть gulp-проект (до сегодняшнего дня я еще никогда не прибегал к его помощи) и сосредоточиться непосредственно на кодинге. К сожалению, этого оказалось недостаточно.

В процессе верстки стало понятно, что огромные полотна html- и js-кода с каждой строчкой все больше и больше замедляют процесс верстки. Если честно, данная проблема возникала и раньше, а сегодня встала особенно остро.

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

Порывшись в интернете, нашел плагин gulp-rigger. Получаса хватило для того, чтоб понять, что это совсем не то, что нужно:

В октябре прошло года мы объявили о нашем намерении поддержать ORTC в Microsoft Edge с особым фокусом на аудио/видео-коммуникации. С тех пор мы много над этим работали и сегодня рады анонсировать, что превью-версия нашей реализации доступна в свежей сборке Edge в рамках программы Windows Insider.



Поддержка ORTC в Microsoft Edge является результатом сотрудничества между командами операционных систем (OSG) и Skype. Объединив вместе 20-летний опыт построения веб-платформы и 12-летний опыт создания одного из крупнейших сервисов коммуникации в реальном времени для обычных и бизнес-пользователей, мы поставили перед собой цель сделать возможным построение в браузере опыта общения не только с пользователями Skype, но и другими коммуникационными сервисами, совместимыми c WebRTC.

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

От переводчика: данная статья написана Дядюшкой Бобом в августе 2012 года, но, на мой взгляд, вполне актуальна до сих пор.



За последние несколько лет мы видели целый ряд идей относительно архитектуры систем. Каждая из них на выходе давала:

1. Независимость от фреймворка. Архитектура не зависит от существования какой-либо библиотеки. Это позволяет использовать фреймворк в качестве инструмента, вместо того, чтобы втискивать свою систему в рамки его ограничений.
2. Тестируемость. Бизнес-правила могут быть протестированы без пользовательского интерфейса, базы данных, веб-сервера или любого другого внешнего компонента.
3. Независимоcть от UI. Пользовательский интерфейс можно легко изменить, не изменяя остальную систему. Например, веб-интерфейс может быть заменен на консольный, без изменения бизнес-правил.
4. Независимоcть от базы данных. Вы можете поменять Oracle или SQL Server на MongoDB, BigTable, CouchDB или что-то еще. Ваши бизнес-правила не связаны с базой данных.
5. Независимость от какого-либо внешнего сервиса. По факту ваши бизнес правила просто ничего не знают о внешнем мире.

Диаграмма в начале этой статьи — попытка объединить все эти идеи в единую эффективную схему.

Сколько уже было сломано копий о задачу выравнивания элементов на странице. Предлагаю вашему вниманию перевод отличной статьи с решением этой проблемы от Стефана Шоу (Stephen Shaw) для Smashing Magazine — Absolute Horizontal And Vertical Centering In CSS.

Все мы знали о margin: 0 auto; для горизонтального центрирования, но margin: auto; не работало для вертикального. Это можно легко исправить, просто задав высоту и применив следующие стили:

.Absolute-Center {
  margin: auto;
  position: absolute;
  top: 0; left: 0; bottom: 0; right: 0;
}

Я не первый, кто предложил это решение, однако такой подход редко применяется при вертикальном выравнивании. В комментариях к статье How to Center Anything With CSS Simon ссылается на пример jsFiddle, где приводится отличное решение для вертикального центрирования. Вот еще несколько источников на эту тему.

Рассмотрим способ поближе.

Update: Часть сведений в данной статье устарели. Рекомендую свежие материалы на css-live.ru.

Введение

Модуль CSS3 Grid Layout — это один из самых интересных, на мой взгляд, модулей в семействе CSS3. Официальная история модуля в виде черновика спецификации насчитывает сегодня чуть менее года. О предварительном анонсе еще с названием CSS Grid Alignment на TPAC 2010 Владимир Юнев писал еще в декабре 2010. Надо также отметить, что с чуть другим названием и несколько отличным синтаксисом, но с той же сутью, он был заявлен в качестве WD еще в 2007г. Сегодня работы по доводке модуля идут полным ходом, предварительная реализация уже есть в Internet Explorer 10 и есть надежда, что поддержка новых возможностей также появится в будущих версиях других популярных браузеров.

Зачем нужен Grid Layout?

Задача, которую решает модель CSS3 Grid Layout, очень проста и понятна любому веб-верстальщику (да и не только ему): предоставить удобный механизм расположения контента по виртуальной сетке.

В отличие от старых табличных подходов, основанных на использовании table, здесь не замусоривается семантика документа и представление четко отделено от содержания. В отличие от различных вариаций блочной верстки со становящимися при сколь-нибудь сложной структуре безумными и многоэтажными float'ами в сочетании с вручную просчитанными отступами, здесь описание стилей становится тривиально простым и прозрачным. В отличии от абсолютного позиционирования с привязкой к координатам, здесь сохраняется гибкость. В отличие от популярных сегодня css/js-библиотек для разметки по сетке путем указания соответствующих классов (взять хоть те же bootstrap или yui css grids), здесь не замусоривается привязка классов.

Сплошное удовольствие! Осталось только дождаться широкой поддержки :) Впрочем, если вы планируете делать приложения в стиле Metro для Windows 8 на html/js, ключевые возможности, описываемые в модуле CSS3 Grid Layout, уже работают — и можно двигаться вперед, используя удобные и практичные механизмы.

Разрешите представить вам перевод статьи Нолана Лоусона «У нас проблемы с промисами», одной из лучших по теме из тех, что мне доводилось читать.

У нас проблемы с промисами

Дорогие JavaScript разработчики, настал момент признать это — у нас проблемы с промисами.

Нет, не с самими промисами. Их реализация по спецификации A+ превосходна. Основная проблема, которая сама предстала передо мной за годы наблюдений за тем, как многие программисты борются с богатыми на промисы API, заключается в следующем:

— Многие из нас используют промисы без действительного их понимания.

Если вы мне не верите, решите такую задачку:

Вопрос: В чем разница между этими четырьмя вариантами использования промисов?

doSomething().then(function () {
  return doSomethingElse();
});

doSomething().then(function () {
  doSomethingElse();
});

doSomething().then(doSomethingElse());

doSomething().then(doSomethingElse);

Кто пишет на Node.js и использует MySQL, тот непременно знает, что наш дорогой товарищ Felix Geisendörfer три года назад совершил героический и самоотверженный подвиг: в одиночку разработал очень качественный драйвер для подключения к MySQL, нативно реализовав двоичный протокол этой СУБД на JavaScript. Потом к проекту подключились другие уважаемые товарищи, была реализована поддержка пулов соединений, кластеров, транзакций, восстановление при временной утере соединения и т.д. Сейчас драйвер является самым развитым, хорошо проработанным и активно поддерживаемым из того, что мы имеем в открытых репозитариях npm и github. Удивительно даже, что при хорошо проработанной низкоуровневой реализации, все удобства, которые предоставляет это драйвер для прикладного разработчика, сводятся к одному методу query. Для меня лично, этого очень мало, ну привык дедушка к удобствам для возврата скалярных значений, строк и столбцов в массивы, интроспекции структур БД. Так что, с удовольствием делюсь этими наработками с вами, мои дорогие Хабравчане, но предупреждаю, что все удобства будут на улице. Есть конечно вариант тесной интеграции с драйвером, но FelixGe желает оставить драйвер исключительно низкоуровневым, поэтому я остановился на варианте внешней библиотеки с добавлением к драйверу через примеси. В виде примесей, удобства попали и в платформу Impress, а так же, опубликованы как патч к драйверу. О функционале и вариантах использования далее.

Недавно я снова исследовал вопрос загрузки шрифтов, так как я хотел использовать локальную копию шрифта и сделать ее загрузку максимально быстрой и эффективной. Данный подход существенно отличается от того, когда вы используете TypeKit или шрифты Google и простые сниппеты «копировать/вставить».

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

1, 2, 3

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

Цели:

1. Асинхронно загружать веб-шрифты
2. Избежать сильного пересчета положения в макете
3. Как можно быстрее загружать веб-шрифты
4. Избежать загрузки шрифтов для возвращающихся посетителей

А теперь давайте попробуем добиться наших целей поэтапно: