От переводчика: когда я начал разбираться с MVC-фреймворками для фронт-энда, каким-то чудом попалась на глаза эта статья Henrik Joreteg. Сейчас дошли руки перевести ее для Хабра, тем более, что об AmpersandJS на Хабре вообще не слышно. Попробую организовать цикл статей по этому инструменту ребят из &yet, мне кажется, он достоин внимания.



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

Angular.js

за

1. очень легко начать использовать. можно просто вставить тег script, добавить немного ng- атрибутов в ваше приложение, и вы волшебным образом получаете нужное вам поведение
2. Angular хорошо поддерживается его основной командой разработчиков, многие из которых работают в Гугле на постоянной основе
3. большая аудитория/сообщество

IT-специалистам несложно настроить резервное копирование дома, например, с помощью rsync, созданием rar-архивов планировщиком задач, инкрементальным копированием в интернет (не говоря уже о настройке tar+cron или bacula на работе). Однако неспециалисты (для дома) будут использовать программы резервного копирования, которые много проще. Рассмотрим программу, скрывающей за привычной простотой для домашнего пользователя, гибкий и хорошо продуманный инструмент резервного копирования.

В этой статье речь пойдет о бесплатной версии Genie Timeline — Free (Noncommercial), с незначительными ограничениями и отличиями от платных версий (например, нет бэкапа с телефонов Blackberry). Стоит упомянуть, что Pro-версии используют такие компании, как NASA, Siemens, NEC, ZyXEL и Philips.

В этой небольшой статье я хотел бы рассказать о средствах мониторинга, использующихся для анализа работы DWH нашего банка. Статья будет интересна всем, кого не устраивают существующие готовые системы мониторинга и кого посещали мысли собрать таковую «под себя» из отдельных кусочков. Большое внимание в статье уделяется дашборду Grafana, который, по моему мнению, незаслуженно обделён вниманием на Хабре. По большинству компонентов системы мониторинга будет вкратце рассмотрен процесс инсталяции (под RedHat).


Тёплый ламповый дашборд

На различных конференциях мы неоднократно рассказывали про наше облако для CLI-скриптов (видеозапись доклада, слайды). Облако предназначено для того, чтобы запускать различные PHP-скрипты по расписанию или через API. Как правило, эти скрипты обрабатывают очереди, и нагрузка «размазывается» приблизительно по 100 серверам. Ранее мы акцентировали внимание на том, как реализована управляющая логика, которая отвечает за равномерное распределение нагрузки по такому количеству серверов и генерацию заданий по расписанию. Но, помимо этого, нам потребовалось написать демон, который был бы способен запускать наши PHP-скрипты в CLI и следить за статусом их исполнения.

Изначально он был написан на Си, как и все остальные демоны в нашей компании. Однако мы столкнулись с тем, что существенная часть процессорного времени (около 10%) тратилась, по сути, впустую: это запуск интерпретатора и загрузка «ядра» нашего фреймворка. Поэтому, чтобы иметь возможность инициализировать интерпретатор и наш фреймворк только один раз, было принято решение переписать демон на PHP. Мы назвали его Phprocksyd (по аналогии с Phproxyd — PHP Proxy Daemon, демоном на Си, который у нас был до этого). Он принимает запросы на запуск отдельных классов и делает fork() на каждый запрос, а также умеет сообщать о статусе исполнения каждого из запусков. Такая архитектура во многом похожа на модель веб-сервера Apache, когда вся инициализация делается один раз в «мастере» и «дети» занимаются уже именно обработкой запроса. В качестве дополнительной «плюшки» мы получаем возможность включить opcode cache в CLI, который будет правильно работать, поскольку все дети наследуют ту же область общей памяти, что и мастер-процесс. Чтобы уменьшить задержки при обработке запроса на запуск, можно делать fork() заранее (prefork-модель), но в нашем случае задержки на fork() составляют около 1 мс, что нас вполне устраивает.

В этом посте вы узнаете о новой фиче Marionette.js — Behaviors.

Очень часто в различных элементах интерфейса у нас встречаются похожие элементы управления (например кнопка «Удалить» может быть и у категорий, и у записей, и в списке зарегистрированных пользователей… да везде), и каждый раз приходится описывать обработчик этой кнопки в каждом View, причем везде одинаково.
Но это уже называется дублирование кода, и не приветствуется в большинстве общества. Поэтому разработчики Marionette.js предоставили нам такую замечательную фичу как Behaviors.

Behaviors предоставляет интерфейс для изолирования описаний взаимодействия DOM с пользователем в отдельные логические куски кода. Behavior может быть применено к любому View любое количество раз.

В этой статье рассмотрим самый тривиальный пример — кнопка «Удалить».

(Окончание перевода статьи Эдди Османи о сравнении и выборе библиотеки для проекта со значительной ролью JS на клиенте.)
Содержание первой части:

■ Что такое MVC или, лучше сказать, MV*?
■ Когда нам нужен MV*-фреймворк JS?
■ Где же мы будем нуждаться в MV*, а где нет?
■ Проблема выбора: слишком много вариантов?
■ TodoMVC: общее приложение для обучения и сравнения
■ Предложенные нами критерии выбора фреймворка
■ Dojo и усложнение фреймворков на JavaScript
■ Коллекция TodoMVC (фреймворки, на которых сделаны реализации тестового приложения Todo)

В последние годы REST (REpresentational State Transfer) стала стандартной архитектурой при дизайне веб-сервисов и веб-API.

В этой статье я покажу вам как просто создавать RESTful веб-сервисы используя Python и микрофреймворк Flask.

Что такое REST?

Характеристика системы REST определяется шестью правилами дизайна:

• Клиент-Сервер: Должно быть разделение между сервером, который предлагает сервис и клиентом, который использует ее.
• Stateless: Каждый запрос от клиента должен содержать всю информацию, необходимую серверу для выполнения запроса. Другими словами, сервер не обязан сохранять информацию о состоянии клиента.
• Кэширование: В каждом запросе клиента должно явно содержаться указание о возможности кэширования ответа и получения ответа из существующего кэша.
• Уровневая система: Клиент может взаимодействовать не напрямую с сервером, а с произвольным количеством промежуточных узлов. При этом клиент может не знать о существовании промежуточных узлов, за исключением случаев передачи конфиденциальной информации.
• Унификация: Унифицированный программный интерфейс сервера.
• Код по запросу: Сервера могут поставлять исполняемый код или скрипты для выполнения их на стороне клиентов.

Только ленивый ещё не писал о необходимости писать тесты. Но давайте признаемся честно — писать тесты зачастую скучно. Особенно для legacy-кода. Сотни повторяющихся, однообразных строк. Скука. Что с этим можно сделать?


^{Картинка для привлечения внимания. Красивый питон, да? (Автор фото: Paweł Stefaniak)}

Docker в продакшене на Iron.io


Ранее в этом году (прим. 2014 г.), мы приняли решение запускать каждую задачу на IronWorker внутри своего собственного Docker контейнера. С тех пор мы запустили более 300 000 000 программ внутри собственных Docker контейнеров в облаке.

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

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

Я поставил перед собой цель показать возможности Redis с помощью примеров кода. После публикации приму любые предложения по улучшению материала.

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

Ключи

Redis — хранилище данных в формате «ключ-значение». Факты о ключах:

• Ключи в Redis — бинарно-безопасные (binary safe) строки.
• Слишком длинные ключи — плохая идея, не только из-за занимаемой памяти, но так же и в связи с увеличением времени поиска определенного ключа в множестве в связи с дорогостоящим сравнением.
• Хорошая идея — придерживаться схемы при построении ключей: «object-type:id:field».

Типы данных Redis

• Строки (strings). Базовый тип данных Redis. Строки в Redis бинарно-безопасны, могут использоваться так же как числа, ограничены размером 512 Мб.
• Списки (lists). Классические списки строк, упорядоченные в порядке вставки, которая возможна как со стороны головы, так и со стороны хвоста списка. Максимальное количество элементов — 2³² — 1.
• Множества (sets). Множества строк в математическом понимании: не упорядочены, поддерживают операции вставки, проверки вхождения элемента, пересечения и разницы множеств. Максимальное количество элементов — 2³² — 1.
• Хеш-таблицы (hashes). Классические хеш-таблицы или ассоциативные массивы. Максимальное количество пар «ключ-значение» — 2³² — 1.
• Упорядоченные множества (sorted sets). Упорядоченное множество отличается от обычного тем, что его элементы упорядочены по особому параметру «score».

Про типы данных Redis есть отдельная хорошая статья: «Структуры данных, используемые в Redis».

Ранее я показал элементарную реализацию алгоритма шинглов, позволяющую определять, являются ли два документа почти дубликатами или нет. В этот раз я поясню реализацию алгоритма, описанную Зеленковым  Ю. Г. и Сегаловичем И.В. в публикации «Сравнительный анализ методов определения нечетких дубликатов для Web-документов».
Этим я начинаю серию из трех теоретических статей, в которых постараюсь доступным языком описать принцип алгоритмов шинглов, супершинглов и мегашинглов для сравнение веб-документов.

Введение

Любому системному администратору постоянно приходится иметь дело с данными, представленными в форме временных рядов (time series): статистика скачивания файлов, статистика запросов к серверам, данные об использовании системных и аппаратных ресурсов виртуальными машинами…

Чтобы все это хранить и обрабатывать, нужен адекватный и производительный инструмент.

Обработка текста в поисковом движке выглядит достаточно простой снаружи, однако на самом деле это сложный процесс. При индексации текст документов должен быть обработан стриппером HTML, токенайзером, фильтром стоп-слов, фильтром словоформ и морфологическим процессором. А ещё при этом нужно помнить про исключения (exceptions), слитные (blended) символы, N-граммы и границы предложений. При поиске всё становится ещё сложнее, поскольку помимо всего вышеупомянутого нужно вдобавок обрабатывать синтаксис запроса, который добавляет всевозможные спец. символы (операторы и маски). Сейчас мы расскажем, как всё это работает в Sphinx.

Картина в целом

Упрощённо конвейер обработки текста (в движке версий 2.х) выглядит примерно так:



Выглядит достаточно просто, однако дьявол кроется в деталях. Есть несколько очень разных фильтров (которые применяются в особом порядке); токенайзер занимается ещё чем-то помимо разбиения текста на слова; и наконец под «и т.д.» в блоке морфологии на самом деле находится ещё по меньшей мере три разных варианта.

Поэтому более точной будет следующая картина:

Пример работы алгоритма на сайте Автокадабра.

Задача

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

Гораздо полезней отследить взаимодействие посетителей с сайтом, выяснить чем живёт сайт, с возможностью охватить одновременно множество посетителей. В итоге, появилась идея записывать информацию в виде осмысленного списка действий посетителей:

• Dima: переход на сайт с поисковой системы Yandex RU по запросу sepyra (3м. 10 сек. назад)
• Dima: переход со страницы "Веб-аналитика Sepyra | Официальный сайт" на страницу "О системе | Веб-аналитика Sepyra (1 м. 30 сек. назад)
• Dima: выделение текста "времени" в блоке "Одна из ключевых особенностей веб-аналитики Sepyra — возможность… кто хочет быть в курсе каждого шага посетителей" (40 сек. назад)
• Dima: средний интерес к подблоку "Подключиться" в блоке "Тарифы О системе FAQ Контакты Русский English Подключиться Войти" (20 сек. назад)
• Dima: заполнение/изменение поля "Ваше имя" в форме "Регистрация" (10 сек. назад)

Запись состоит из двух частей: блок в котором происходит действие посетителя и само действие, например — выделение текста "времени" в блоке "Одна из ключевых особенностей ...". Для этого описания необходимо определить блок на странице и его имя. Если с именем было более-менее понятно, то над выделением блоков пришлось подумать.

В предыдущей статье мы рассмотрели основные понятия и термины в рамках технологии Data Mining. Сегодня более детально остановимся на Web Mining и подходах к извлечению данных из веб-ресурсов.

Web Mining — это процесс извлечения данных из веб-ресурсов, который, как правило, имеет больше практическую составляющую нежели теоретическую. Основная цель Web Mining — это сбор данных (парсинг) с последующим сохранением в нужном формате. Фактически, задача сводится к написанию HTML парсеров, и как раз об этом поговорим более детально.

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

В статье речь пойдет о технологии WebSocket. Точнее не о самой технологии, а о том, как ее можно использовать. Я давно слежу за ней. Еще когда в 2011 году один мой коллега прислал мне ссылку на стандарт, пробежав глазами, я как-то расстроился. Выглядело настолько круто, и я думал, что в момент, когда это появится в популярных браузерах, я уже буду планировать, на что потратить свою пенсию. Но все оказалось не так, и как гласит caniuse.com WebSocket не поддерживается только в Opera Mini (надо бы провести голосование, как давно кто-либо видел Opera Mini).

Кто трогал WebSocketы руками, тот наверняка знает, что работать с API тяжело. В Javascript API достаточно низкоуровневый (принять сообщение — отправить сообщение), и придется разрабатывать алгоритм, как этими сообщениями обмениваться. Поэтому и была предпринята попытка упростить работу с вебсокетами.

Так и появился WSRPC. Для нетерпеливых вот простое демо.

Наглядный пример задачи — сайт vk.com. Каждый раз, когда вы воспроизводите музыку или видео в одной вкладке, в других вкладках воспроизведение останавливается. И если вы обратитесь в интернет за помощью в решении данной задачи, то наверняка найдете описание Storage Events или Page Visibility API или даже готовые решения, к примеру Visibility.js.

На хабре уже был обзор этих вещей, к примеру вот и ещё.



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

Листая на Хабре раздел Python наткнулся на интересную статью о библиотеке NetworkX. Впечатлившись красивыми графами, решил повысить свой python-скилл и покопаться в networkx.

Пролог

Первый вопрос — откуда взять данные для визуализации? Генерировать случайные не интересно, они и в комплекте модуля были. Тут вспомнилась Dos утилитка tree, выводящая каталоги файловой системы в виде дерева. Решено было написать красивый аналог на Python и нарисовать все в networkx с помощью matplotlib.

Многие используют фильмы с субтитрами, чтобы слушать речь и одновременно читать. Хочу предложить альтернативу — слушать аудио книги и читать их текст с подстрочным переводом и доступом к каждой отдельной фразе. Они доступны онлайн на сайте BookTitres.com .

Самое интересное

Уже доступные для чтения книги вы можете найти в разделе "Слушайте и читайте" на сайте. Книга "Хоббит" закончена — это 11 часов аудио и 13800 фраз. Пройдя её полностью, вы ощутите заметное улучшение своего английского. Особенно, если будете повторять за чтецом каждую фразу. От других книг в основном сделаны несколько первых глав. Если хотите продолжения — ответьте на опрос и укажите желаемую книгу.

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

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