Меньше чем за год Walmart.com завершил миграцию на React/Node.js, и мы рады сообщить вам об этом! Цель миграции заключалась в создании новой платформы для повышения эффективности WalmartLabs и ее инженеров в будущем.

Мы рады сообщить о том, что мы выложили в open source Electrode — платформу, на которой построен Walmart.com.

1. Введение

В данной статье я хотел бы рассказать об этих трёх буквах, постоянно находящихся на слуху, но для многих являющихся тайной за семью печатями, а так же привести ряд ресурсов, с которыми неплохо было бы познакомиться при желании продолжить развитие в проектировании на основе предметной области (DDD: Domain Driven Design).

БЭМ набирает популярность и становится актуальнее — например, недавно Google выпустил новую библиотеку блоков под названием Material Design Lite, реализованную по БЭМ-методологии. Команда БЭМ тоже не сидела без дела — мы выпустили новую версию библиотеки bem-components, на базе которой построены сайты и проекты не только Яндекса, но и других разработчиков.

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



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

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

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

Оговорюсь сразу, что развивать будем версию на MatreshkaJS, а не на Angular.

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

Мы в Хекслете используем JavaScript не только для очевидных задач во фронтэнде, но и, например, для реализации браузерной среды разработки (наш опен-сорсный hexlet-ide) на React'е. У нас есть практический курс по JavaScript, и один из уроков там посвящен замыканиям. Это важная тема не столько в рамках JS, сколько в программировании вообще. Мы освещаем ее и в других курсах.

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

Я использую замыкания уже достаточно давно. Я научился их использовать, но не до конца понимал как они на самом деле работают, что происходит «под капотом». Что это вообще такое? Википедия не очень помогает. Когда замыкание создается и уничтожается? Как выглядит реализация?

"use strict";
 
var myClosure = (function outerFunction() {
 
  var hidden = 1;
 
  return {
    inc: function innerFunction() {
      return hidden++;
    }
  };
 
}());
 
myClosure.inc();  // возвращает 1
myClosure.inc();  // возвращает 2
myClosure.inc();  // возвращает 3
 
// Ага, круто. А как это реализовано?
// И что происходит под капотом?

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

Что такое Kubernetes?

Kubernetes является проектом с открытым исходным кодом, предназначенным для управления кластером контейнеров Linux как единой системой. Kubernetes управляет и запускает контейнеры Docker на большом количестве хостов, а так же обеспечивает совместное размещение и репликацию большого количества контейнеров. Проект был начат Google и теперь поддерживается многими компаниями, среди которых Microsoft, RedHat, IBM и Docker.

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

Внимание! Реклама! Пост оплачен Капитаном Очевидность!

Ниже под катом вы найдёте 15 пунктов, описывающих правильную организацию ресурсов, доступных по протоколу HTTP — веб-сайтов, «ручек» бэкенда, API и прочая. «Правильный» здесь означает «соответствующий рекомендациям и спецификациям». Большая часть ниженаписанного почти дословно переведена из официальных стандартов, рекомендаций и best practices от IETF и W3C.



Вы не найдёте здесь абсолютно ничего неочевидного. Нет, серьёзно, каждый веб-разработчик теоретически эти 15 пунктов должен освоить где-то в районе junior developer-а и/или второго-третьего курса университета.

Однако на практике оказывается, что великое множество веб-разработчиков эти азы таки не усвоило. Читаешь документацию к иным API и рыдаешь. Уверен, что каждый читатель таки найдёт в этом списке что-то новое для себя.

Немного о мотивах

Доброго времени суток, уважаемые хабровчане. Некоторое время назад, я познакомился с библиотекой RivetsJS. Она мне пришлась по вкусу, хотя содержит в себе только инструменты для data-binding. Сразу хочу сказать, что даже не собираюсь спорить, для этих вещей есть замечательные AngularJS и др. фреймворки, но лично я не вижу смысла подключать такой мощный инструмент, как Angular, если мне требуется только малая толика его возможности. Поэтому, для этих целей, я выбрал именно RivetsJS. И вот, воодушевленный идеей перевести его документацию на русский, я пишу эту статью. Мотив простой — рассказать об этой библиотеке, и я не нашел ничего лучше, чем просто перевести её документацию, которая, возможно только на мой взгляд, написана на немного «ломаном» английском. Итак, поехали.

P.S. Сразу попрошу прощения, это мой первый перевод, возможно я не супер-пупер переводчик. Если вам что-то покажется нелепым или вы найдете ошибку — прошу сообщить об этом мне, я сразу же её исправлю. Заранее, спасибо.

Документация RivetsJS

Гайд

• Установка
• Использование
• Биндинг
• Форматеры
• Компоненты
• Адаптер
• Свойства
• Итерации биндинга

Справочник

• text
• html
• show
• hide
• enabled
• disabled
• if
• unless
• value
• checked
• unchecked
• on-[event]
• each-[item]

Это перевод поста Steven Luscher опубликованного в блоге Babel. Steven работает в Facebook над Relay – JavaScript фрэймворком для создания приложений с использованием React и GraphQL.

За этот год, в процессе реорганизации Instagram Web, мы насладились использованием ряда особенностей ES6+, при написании нашх React компонентов. Позвольте мне остановиться на тех моментах, когда новые возможности языка могут повлиять на то как вы пишите React приложения, и сделают этот процесс легче и веселее, чем когда-либо.

Доброго времени суток.



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

Представляю вашему вниманию github.com/DavidKlassen/es6-browser-boilerplate.

В основу шаблона лег github.com/babel/babel-library-boilerplate, но gulpfile.js был основательно почищен и упрощен. Многие зависимости я убрал и оставил возможности, которые необходимы для разработки приложений для браузеров.

Основные цели, которые я преследовал:

• Шаблон должен быть хорошей стартовой точкой для разработки SPA и third party SDK.
• Минималистичность и расширяемость.
• Весь код, то есть и само приложение и тесты можно писать на ES6.

Вступление

Привет всем хабровчанам, любителям Yii и Node.js.
Это вторая статья про фреймворк Jii (GitHub), в предыдущей статье мы рассматривали Объекты доступа к данным и конструктор запросов (Query Builder).
Как и обещал, в этой статье я расскажу про использовании Active Record.

Active Record

Как известно, для обработки соединений NGINX использует асинхронный событийный подход. Вместо того, чтобы выделять на каждый запрос отдельный поток или процесс (как это делают серверы с традиционной архитектурой), NGINX мультиплексирует обработку множества соединений и запросов в одном рабочем процессе. Для этого применяются сокеты в неблокирующем режиме и такие эффективные методы работы с событиями, как epoll и kqueue.

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

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

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

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

Google, Microsoft, Mozilla и инженеры проекта WebKit 17 июня сделали анонс, что они объединились для запуска WebAssembly, нового бинарного формата для компилирования веб-приложений.

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

Моделирование целевой аудитории (персонажей) и написание «пользовательских историй» (user story) были эффективными, когда клиенты и разработчики продуктов находились далеко друг от друга. Теперь все по-другому. В этом посте говорится о том, как одна команда разработчиков применила метод Job Stories для создания страницы профиля пользователя.

[ Первая часть ]

В этом посте будет то, что не поместилось в первую часть. Это некоторые операторы, которые есть в aggregation framework и достаточно вольный перевод трех статей из раздела экоситема на сайте со справкой к MongoDB, описывающих некоторые случаи применения для интернет-коммерции.

Случаи использования разделены там на восемь статей, которые условно можно разделить на три группы. Мне показались самыми интересными для перевода три материала, связанные с e-commerce.

1. Операторы в aggregation framework
2. Каталог продуктов
3. Корзина и управления остатками на складе
4. Иерархия категорий

В предыдущих частях от iv_s (раз два три) были описаны различные техники использования C и Ruby вместе. Я бы хотел рассказать о еще одной возможной связке – использовании уже существующих системных C-функций.

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

Как оказалось, достучаться до функций работы с шиной I2C в Ruby предельно просто – он позволяет использовать уже написанные и установленные библиотеки на C.



Схема работы такая:
на RaspberryPi запущен Sinatra сервер, который при обращении отдает данные о повороте платы по осям X и Y, а также расстояние до ближайшего препятствия в сантиметрах.
На клиенте для визуализации и отладки написан простой скрипт с использованием Raphael3d.js, который каждые 100мс опрашивает устройство и поворачивает схематическую плату в соответствии с положением платы физической.

Интро

Не так давно я выступал на конференции FrontendConf 2015 (РИТ++) с темой данной статьи. И при подготовке доклада начал искать информацию, а кто вообще выступал на данную тему и что есть в Сети на данный момент.

Оказалось, что информации совсем немного, более-менее можно было бы отметить доклад mikewest.org/2013/09/frontend-security-frontendconf-2013 от Mike West из компании Google, но какой-то «непентестерский» взгляд и уж совсем мало материала. И www.slideshare.net/eoftedal/web-application-security-in-front-end где тема раскрыта более детально, но выступление 2011 года. А за 4 года технологии и атаки на месте не стояли.

Долго и сложно выбирая темы, что же все-таки рассказать разработчикам фронтендов про безопасность, при этом минимум касаясь бекэнда (местами все-таки это неделимо), получился доклад, а здесь — его текстовый пересказ.

О чем вообще разговор?

А действительно, о чем тут вообще можно разговаривать? Говоря про взломы и безопасность невольно приходят в голову тезисы — слили базу, получили доступ к выполнению команд ОС на сервере, прочитали чужую переписку. Но это все — server side код. А что ж может «нагородить» фронтэндер? Главная опасность, конечно же, в обходе атакующим SOP — Same Origin Policy, главной политики безопасности браузеров, которая регулирует работу в разных Origin. Но не только, давайте разбираться.

Предлагаю читателям «Хабрахабра» перевод публикации «Is ReactJS really fast?» из блога компании 500Tech.

tl;dr; Нет.

Большинство разработчиков считают само собой разумеющимся, что ReactJS — это супер быстрый движок по сравнению
с другими более тяжеловесными фреймворками, такими как AngularJS и EmberJS.

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