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

Вы никогда не задумывались, как выглядит код на JavaScript для программиста, у которого родной язык — английский? Представьте, насколько удобнее им читать и писать код на своем «нативном» языке, насколько ускоряется время разработки и уменьшается количество багов. А ведь использование английского языка как основы для языков программирования не обусловлено ничем, кроме того, что «так исторически сложилось».

Большинство создают внешние ссылки через target="_blank" и не знают одного интересного нюанса — страница, на которую мы попадем таким образом, получит частичный контроль над ссылающейся на нее страницей через js свойство window.opener.

Через window.opener.location мы сможем сделать редирект на, к примеру, фишинговую страницу. Это своего рода tabnabbing, только более продвинутый. Так как жертва меньше всего ожидает подмены страницы, в открытой ранее, доверенной вкладке браузера.

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

Зачем всё это

Мы — маленькая компания, наш штат составляет порядка 50 человек, 20 из которых разработчики. Сейчас у нас 4 команды разработки, в каждой из которых сидит по 5 fullstack разработчика. Но одно дело называть себя fullstack-разработчиком, а другое — действительно хорошо разбираться в тонкостях работы SQL Server'а, ASP.NET, разработке на C#, OOP, DDD, знать HTML, CSS, JS и уметь этим всем разумно пользоваться. Конечно каждый разработчик тяготеет к чему-то своему, но все мы, так или иначе, специалисты именно в разработке на .NET и 90% кода мы пишем на C#.
Наш продукт — система автоматизации маркетинга, — подразумевает большой объем настроек для каждого конкретного клиента. Для того, чтобы наши менеджеры могли заниматься настройкой продукта под клиентов, есть административный сайт, в котором можно заводить рассылки, создавать триггеры и другие механики, кастомизировать сервисы и многое другое. Этот административный сайт содержит много различного нетривиального UI'а, и чем более тонкие моменты мы даём настраивать, чем большее количество фич мы выпускаем в продакшн, тем более интересным UI становится.

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

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

И все же зачем..?

Действительно, можно нафантазировать большое количество количество возможных проблем, например:

• Недоступность удаленного репозитория и отсутсвие актуальной локальной копии
• Злоумышленники с помощью украденного пароля испортили/удалили репозитории
• Ошибки в манипуляциях с репозиториями

Итак, что и как бэкапить...

iBeacon и Eddystone — это сервисы Apple и Google соответственно, использующие BLE (Bluetooth Low Energy) для локального позиционирования внутри помещений. Базовый принцип у обоих сервисов одинаков, отличается лишь формат передаваемых данных. Маяк (передатчик) периодически, с интервалом от долей секунды до нескольких секунд, передаёт пакеты стандарта Bluetooth LE, которые содержат помимо заголовка дополнительную информацию. Технология не предназначена для точного определения положения в помещении, а лишь для фиксирования момента приближения на некоторое близкое расстояние к маяку.
Классический пример использования маяков — музеи. Приходя в музей, вы устанавливаете на смартфон специальное приложение и отправляетесь осматривать экспозицию. Приближаясь к экспонату (маяку) на некоторое расстояние, смартфон это фиксирует и выводит на экран экскурсионную информацию.
В продаже можно найти немало готовых маяков, но сегодня мы соберем прототип собственного маяка (как iBeacon, так и Eddystone) на микроконтроллере SAML21 и BLE модуле BTLC1000 от Atmel.

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

Пара примеров:

• Как работает API нашего IaaS-провайдера
• Как мы разработали свой DNS-менеджер

Сегодня мы решили взглянуть на западный опыт и кратко проанализировать тему балансировки нагрузки. Нас привлекла заметка на тему работы с DDoS-атаками.

Привет всем жителям и гостям хабра и с новым годом! :)
В этой статье я хочу рассказать о том, с какими фичами Jii вступил в 2016-й год и что его в ждет в новом году.

Итак, начнем по порядку.

Привет всем хабровчанам, любителям Yii и Node.js. Давно небыло статей про Jii, но работа не стояла на месте и мне есть что рассказать!
В этой статье мы рассмотрим способы конфигурирования приложения и запуск приложений как несколько процессов.

Реляционные базы данных (РБД) используются повсюду. Они бывают самых разных видов, от маленьких и полезных SQLite до мощных Teradata. Но в то же время существует очень немного статей, объясняющих принцип действия и устройство реляционных баз данных. Да и те, что есть — довольно поверхностные, без особых подробностей. Зато по более «модным» направлениям (большие данные, NoSQL или JS) написано гораздо больше статей, причём куда более глубоких. Вероятно, такая ситуация сложилась из-за того, что реляционные БД — вещь «старая» и слишком скучная, чтобы разбирать её вне университетских программ, исследовательских работ и книг.

На самом деле, мало кто действительно понимает, как работают реляционные БД. А многие разработчики очень не любят, когда они чего-то не понимают. Если реляционные БД используют порядка 40 лет, значит тому есть причина. РБД — штука очень интересная, поскольку в ее основе лежат полезные и широко используемые понятия. Если вы хотели бы разобраться в том, как работают РБД, то эта статья для вас.

В среде веб-разработчиков все больше распространяется знание о том, что скорость важна. Многие стараются ускориться: используют сжатие gzip, минификацию, кеширующие заголовки, сокращение запросов, оптимизацию картинок и другие.

После выполнения этих рекомендаций возникает вопрос: а что именно мы оптимизируем? Оказывается, что в большинстве случаев это время полной загрузки страницы со всеми элементами. Однако, это не совсем то, что нужно. На самом деле важно время, за которое пользователь получает «первый экран» страницы с важными функциональными элементами (заголовок, текст, описание товара и т.д.) Другими словами, важен момент начала рендеринга страницы. Здесь и возникает критический путь рендеринга, который определяет все действия, которые должен выполнить браузер для начала отрисовки страницы. С этой штукой мы и будем разбираться в статье.

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

С наших Download-серверов каждый день скачивается несколько миллионов драйверов (статичных .exe и .zip файлов). Для анализа поведения пользователей перед нами встала задача посчитать следующие параметры: когда, сколько, как часто и даже кто именно скачивает драйверы.

Самым очевидным решением было бы использовать инструменты типа AWstat, GoAccess, ELK stack или Splunk, а в крайнем случае собирать логи Nginx.

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

И тогда мы решили заставить Nginx самостоятельно отправлять события в Google Analytics сразу же после скачивания файла. Мы также смогли передать в GA уникальный идентификатор пользователя ClientID.
В результате мы получили аналитику по статичным файлам, к которым раньше невозможно было привязать счетчик GA.

Под катом готовый конфиг и примеры работы нашей системы.

Вступление

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

Active Record

JavaScript – один из главных языков нашего стека в Хекслете. Мы используем ReactJS и NodeJS в интерактивных частях платформы, и сделали вводный курс (более продвинутые – на подходе). Любовь к JS помогла опубликовать этот перевод хорошего эссе «Prototypes are Objects (and why that matters)».

Этот пост рассчитан на тех, кто знаком с объектами в JavaScript и знает, как прототип определяет поведение объекта, что такое функция-конструктор и как свойство .property конструктора относится к объекту, который он конструирует. Общее понимание синтаксиса ECMAScript 2015 тоже не помешает.

Мы всегда могли создать класс в JavaScript таким образом:

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

Вступление

Привет всем хабровчанам, любителям Yii и Node.js. Почему объединены любители PHP-фреймворка и серверного JavaScript?
Потому что Yii теперь доступен и на JavaScript (как для Node.js, так и для браузера)!

В этой статье мы рассмотрим Query Builder, полностью сохранивший API от Yii2 и работающий на Node.js.
Конструктор запросов — это лишь одна из реализованных частей Jii (не путать с Yii), в данной статье я специально не буду рассматривать фреймворк в целом, потому что его вполне можно использовать и частями.

Что такое Jii?

Jii — это компонентный JavaScript MVC фреймворк, который повторяет архитектурные решения легендарного PHP фреймворка Yii 2, в большинстве случаев сохраняя его API. Отсюда происхождение названия Jii — JavaScript Yii.

Доброго времени суток, уважаемый читатель!
Перед каждым новичком в мире языка программирования Common Lisp
возникает проблема выбора среды разработки — Integrated Development Environment (далее, IDE).

Существует большое количество IDE для Common Lisp. Перечислим некоторые, самые распространенные, из них:

• LispWorks IDE (commercial, crossplatform)
• Allegro Common Lisp (commercial, crossplatform)
• LispIDE (open source, Windows 2K/XP/Vista/7)
• Lispbox (open source, crossplatform)
• Emacs + Slime (open source, crossplatform)

В данной статье я подробно расскажу как установить и настроить кроссплатформенную среду разработки для Common Lisp, как скачивать и устанавливать дополнительные библиотеки при помощи quicklisp — менеджера пакетов Common Lisp. Будет много полезных ссылок на ресурсы и материалы по языку.
Речь пойдет о связке GNU Emacs & Slime.
Если Вас интересует Common Lisp, Вам нужна кроссплатформенная, мощная, интерактивная Common Lisp IDE с блэкджеком и дамами дебаггером и дизассемблером (внезапно!), то, прошу под кат…

Перевод статьи «Building robust web apps with React: Part 2, optimising with Browserify», Matt Hinchliffe

От переводчика: это перевод второй части цикла статей «Building robust web apps with React».
Переводы:

• Построение надежных веб-приложений на React: Часть 1, браузерные прототипы
• Построение надежных веб-приложений на React: Часть 2, оптимизация с Browserify
• Построение надежных веб-приложений на React: Часть 3, тестирование с Jasmine
• Построение надежных веб-приложений на React: Часть 4, серверная генерация

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

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

Оригинал: React To The Future With Isomorphic Apps

Изоморфные приложения. Взгляд в будущее с React

В разработке программного обеспечения все часто возвращается на круги своя. Так, например, на заре развития Интернета серверы подгружали контент сразу же на сторону клиента. В последнее же время, с разработкой современных веб-фреймворков, таких как AngularJS и Ember, мы видим тенденцию к обработке запросов на стороне клиента и использованию сервера только для API. Однако, это далеко не единственная тенденция. Сейчас происходит медленное возвращение или, скорее, слияние этих двух архитектур.