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

Предыстория

Хотелось создать своего робота, а так же автоматизировать управление светом и климатом дома. С этой целью начал изучать имеющиеся возможности. Для себя я разделил все решения на две группы: системы в которых код на контроллере выполняется в одном главном цикле (arduino, lego и т.п.) и системы состоящие из параллельно работающих процессов обменивающихся между собой сообщениями.
Интуитивно выбрал вторую группу, так как хотелось найти максимально простое решение с дружественным пользовательским интерфейсом. Из наиболее популярных представителей этого «семейства» очень понравились Microsoft Robotics Studio и ROS. Но к сожалению, на текущий момент, привязать их к конкретному железу весьма не просто, да и разобраться в них с нуля так же весьма не тривиальная задача. В итоге принял решение писать сам, но «кодить» на C очень не хотелось, Душа просила чего-нибудь попроще и полегче. В итоге выбрал Python. А учитывая, что по мимо робота и «умного дома» в голову начало лезть куча других идей, то решил сразу сделать небольшой фреймворк, в котором основной упор был бы сделан на простоту разработки.

Концепция

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



Сеть процессов строится на базе стандартного Python модуля multiprocessing. Система обмена сообщениями и разделяемая память реализованы при помощи Redis.

Каждый Bubot имеет встроенный веб-сервер веб-сервер Tornado, который позволяет контролировать состояние, управлять роботом, на ходу менять параметры (калибровать) робота, а также закладывается возможность обмена данными между роботами.
Bubot не является системой реального времени, хотя Bubot возможно интегрировать с кодом реального времени.

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

Кратко об алгоритме

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

Сама суть метода заключается в том, что мы модулируем эволюционный процесс: у нас есть какая-то популяция (набор векторов), которая размножается, на которую воздействуют мутации и производится естественный отбор на основании минимизации целевой функции. Рассмотрим подробнее эти процессы.

Это перевод третьей части серии статей об открытой Javascript canvas библиотеке Fabric.js.

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

На Хабре уже есть статьи о NoSQL СУБД Tarantool и о том, как его используют в Mail.Ru Group (и не только). Однако нет рецептов того, как работать с Tarantool на Python. В своей статье я хочу рассказать о том, как мы готовим Tarantool Python в своих проектах, какие проблемы и сложности при этом возникают, плюсы, минусы, подводные камни и, конечно же, «в чем фишка». Итак, обо всем по порядку.



Tarantool представляет собой Application Server для Lua. Он умеет хранить данные на диске, обеспечивает быстрый доступ к ним. Tarantool используется в задачах с большими потоками данных в единицу времени. Если говорить о цифрах, то это десятки и сотни тысяч операций в секунду. Например, в одном из моих проектов генерируется более 80 000 запросов в секунду (выборка, вставка, обновление, удаление), при этом нагрузка равномерно распределяется по 4 серверам с 12 инстансами Tarantool. Не все современные СУБД готовы работать с такими нагрузками. Кроме того, при таком количестве данных, очень дорого ожидание выполнения запроса, поэтому сами программы должны быстро переключаться от одной задачи к другой. Для эффективной и равномерной загрузки CPU сервера (всех его ядер) как раз нужен Tarantool и асинхронные приемы в программировании.

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

1. Пребывающая у всех на слуху политика импортозамещения, внедряемая правительством;
2. Популяризация PostgreSQL силами энтузиастов и развитие российского сообщества благодаря таким мероприятиям как PG Day и PGConf;
3. Расширение функциональных возможностей PostgreSQL, позволяющих разработчикам строить гибкие и «schema-less» приложения, не теряя при этом всех преимуществ СУБД, таких как честные транзакции, отказоустойчивость, возможности масштабирования и др.

Нам удалось убедиться в эффективности PostgreSQL несколько лет назад. Внедрение СУБД позволило ликвидировать серьезный технологический кризис на одном из крупных проектов компании. Подробный рассказ об этой success story состоялся на PG Day’14 Russia, прошедшем в прошлом году в Санкт-Петербурге. С тех пор нам довелось попробовать базу данных для решения широкого спектра проблем.

Frontend с каждым днём становится сложнее. Задачи — объёмнее, пользовательский интерфейс — насыщеннее, HTML, CSS и Javascript — огромнее, а сон фронтендера — короче и беспокойнее. Необходимо грамотно структурировать код, выполнять множество рутинных задач (компиляция css- и js-препроцессоров, сборка спрайтов, подготовка и оптимизация изображений, минификация файлов и др). Если вы работаете в команде — это автоматически увеличивает сложность разработки. Чтобы решить эти проблемы, я создал TARS — сборщик html-вёрстки, основанный на gulpjs.

Сегодня мы готовы объявить, что версия Яндекс.Браузера, над которой мы работаем в рамках проекта «Кусто», вливается в его основную бету. Знаем, что здесь многие ею пользуются, и теперь у вас появится возможность переключаться между новым режимом и традиционным интерфейсом.



В конце ноября прошлого года наша команда впервые представила публике свое видение того, каким станет Яндекс.Браузер в будущем. Честно говоря, мы не ожидали, что публичных отзывов окажется так много. Для сравнения: поток предложений и багрепортов, отправленных из Кусто, оказался даже больше, чем после выпуска самой первой версии Яндекс.Браузера в 2012 году. Не удивительно, что весь декабрь мы активно занимались разбором ваших сообщений, которые во многом определили наш фронт работ на ближайшие месяцы.

Мы хотим, чтобы участникам бета-тестирования Яндекс.Браузера было удобно отслеживать изменения в проекте «Кусто» и не приходилось пользоваться для этого двумя разными сборками. А сейчас я расскажу о результатах нашей работы над новым браузером за последний месяц.

[TL;DR]

[ 1-я часть книги ]
[ 2-я часть книги ]
[ 3-я часть книги ]
[ 4-я часть книги ]
[ 5-я часть книги ]
[ 7-я часть книги ]
[ 8-я часть книги ]

Создание системы адаптивной рассылки

Фабио Карнейро

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

Такой адаптивный шаблон не создавался специально под MailChimp, поэтому мне пришлось работать над ним с учетом самых разных ситуаций, в которых email-дизайнеры могли его использовать. В итоге я сформулировал два тезиса: 1) письма должны создаваться так, чтобы их можно было адаптировать под различные задачи и цели и 2) шаблон должен быть доступным на как можно большем количестве почтовых клиентов.

Очередной пост в рамках нашей постоянной рубрики «Лекции Технопарка». В этот раз предлагаем вашему вниманию лекции, посвящённые базам данных. Цель курса — получение студентами знаний в области проектирования реляционных баз данных, эффективной работы с базами данных, оптимизации запросов и схем данных, изучение особенностей использования баз данных в проектах с высокой нагрузкой и/или использующих большие массивы данных, noSQL и его применение для решения прикладных задач в WWW.

О том, как я решил сделать собственный векторный редактор на JavaScript, я писал ранее. К сожалению, выложить полноценный редактор по ряду причин не представляется возможным, поэтому я решил написать небольшой плагин, который позволяет создавать и редактировать контуры, привязывая их к любому отдельному изображению на странице. Разумеется, основной «фишкой» редактора остается возможность полуавтоматического создания контура по принципу инструмента «волшебная палочка» в Photoshop, то есть: кликнул на изображение и получил готовый контур, который затем можно корректировать.

Плагин написан на JavaScript + jQuery, работа с изображением происходит в CANVAS элементе.

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

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



В общем, в прошлом году мы добавили функцию NumberLinePlot в Wolfram Language для визуализации точек, областей и неравенств. Как только пользователи начали работать с NumberLinePlot, мы начали получать просьбы о введении подобной функции, но с датами и временем, поэтому мы решили, что пришло время для TimelinePlot.

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

Я к тому, что в нашем мире любое чтение инструкции — это вынужденная мера. И если уж пользователю нужно что-то прочесть и осознать, лучше подать информацию быстро, понятно и в привязке к реальному миру.

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

Сегодня все очарованы новыми режимами (цифрового) взаимодействия. Есть много интересных и свежих идей относительного того, что может стать доминирующей средой для взаимодействия в будущем. Прикосновение? Жест? Голос? Трекинг глаз?

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

В дискуссиях по поводу дизайна взаимодействия я редко, если вообще когда-либо, вижу упоминание о клавишах быстрого доступа. (Начиная отсюда, я буду говорить о desktop web, так как он использует аппаратную клавиатуру). Это стало возможно, потому что дизайн взаимодействия, в общем и целом, кажется сосредоточенным на веб-дизайне, а сочетания клавиш были отнесены к сфере настольного ПО ^[1] (я не знаю, почему их перенесли не полностью). Однако там, где они есть, они, как правило, используются – я уверен, что проектировщики взаимодействия используют их все время, когда используют Illustrator, Photoshop, Omnigraffle и т.д. По иронии судьбы, горячие клавиши всегда кажутся запоздалой мыслью в конструкциях, созданных этими программами (если о них вообще думают).

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

Существует пара наиболее распространенных способов оповещения пользователя. С одной стороны, социальные сети Facebook, Twitter и LinkedIn указывают определенное число, которое соответствует количеству обновлений. С другой стороны, Trello отображает небольшой красный кружок поверх favicon.


Оповещения Trello, Facebook и Twitter

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

Посмотреть на GitHub
Демо (рус.)

Предлагаем вашему вниманию подборку с ссылками на полезные ресурсы, интересные материалы и IT-новости.

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

Данный пост повествует о том, как я решил эти проблемы.

Дано:

• общее количество статей 140 000;
• количество спама: примерно 16%;
• количество не чётких дубликатов: примерно 63%;

Задача: избавиться от спама и дубликатов, а так же не допустить их дальнейшего появления.

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

Релиз 1.5.0, Buffer.indexOf(), Tessel 2 и многое другое.

Уже закончен долгообещанная третья версия PHPixie ORM компонента. Он теперь полностью независим от фреймворка и может спокойно использоваться сам по себе. В связи с этим, пока продолжается работа над другими компонентами и пишется документация, разработчики составили небольшой туториал для того чтобы можно было уже начать работу с ОРМ. Ниже я предоставлю его перевод и добавлю несколько вещей от себя, но сначала давайте посмотрим чем полезным порадует нас эта версия:

• Большинство ORM используют Model классы, которые используются как для выполнения запросов так и для репрезентации самых записей в базе данных. Например так делают Kohana и Laravel. PHPixie разделила модель на Repository, Entity и Query, каждая из которых имеет строго свое предназначение.
• Кроме SQL баз данных (SQLite, PostgreSQL, MySQL) полностью поддерживается также Mongo. Вы сможете связать отношениями модели с SQL баз данных с моделями хранящимися в коллекциях Mongo.
• Чтобы поддерживать связи между разными базами ( например между таблицами в разных базах в MySQL ) много ORM используют отдельные запросы вместо join-ов и субзапросов. PHPixie же использует субзапросы всегда где это возможно.
• Поддержка встроенных сущностей в Mongo
• На 97% покрыта юнит тестами ( планируется 100% до конца этой недели), и еще на 75% функционалными тестами.
• Эффективное использование Query позволяет уменьшить число запросов к базе. Например вам надо связать все топики автора с какими-то тегами. В большинстве ОРМ вам придется сначала найти топики, потом теги и тогда связать их ( 3 запроса к БД ). PHPixie позволяет сделать это за один запрос. Кстати пример этого есть в туториале снизу

Надеюсь я смог вас заинтересовать, теперь посмотрим на пример с ссылки вверху в переводе: