...Skype — это дьявольски хитрая программа, написанная бесспорно талантливыми людьми..._{Крис Касперски}

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

Skype сейчас я встречаю чаще на компьютерах чем другие IM клиенты, мне он практически заменил icq, вся рабочая переписка ведется в skype, но речь пойдет не о том, что лучше или популярней. Часто бывает так, что участвуешь сразу в нескольких чатах где количество участников превышает 10, что собственно и приводит к тому, что на рабочем столе и в трее постоянно обновляется количество новых сообщений, а также уведомления в виде всплывающих сообщений, а теперь представьте что у вас 3 окна чата с друзьями, 1 с вашим боссом, другой с девушкой — все это в сумме начинает запутывать, отвлекать и порой раздражать. Хотелось бы расставить приоритеты…

Раньше я чаще всего настраивал «политику» уведомлений только через глобальные настройки программы
Случилось так, что я узнал, что в каждом окне чата skype возможно использование команд, например /alertsoff отключит уведомления для конкретного окна чата, соответственно /alertson включит их обратно.
Поискав немного я наткнулся на некое how-to, оказывается у skype чата довольно много текстовых команд, подобие IRC команд. Далее я постарался попробовать все возможные из них на двух имеющихся у меня платформах, как оказалось не все и не везде работает… Прошу под кат.

Здравствуйте, хабрачеловеки! Многие из Вас сталкивались с вынесением бизнес-логики в СУБД в виде хранимых функций/процедур, облегчая клиент. В этом есть как и преимущества, так и недостатки. Сегодня я бы хотел рассказать Вам как создавать хранимые функции в PostgreSQL, написанные на языке C. В статье будут самые основы, которые необходимо знать для начала работы с ними.

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

Что такое спам? Это 80% почтового трафика в интернете и 20% эффективности. Обычная, грамотно сделанная email рассылка, будет в разы эффективнее. Но даже с самыми благими намерениями всегда есть риск попасть в чистилище папки «Нежелательная почта». Чтобы этого избежать, нужно учитывать ряд нюансов.

Как обычно, саммари в начале статьи и дальше — подробные пояснения. Итак, 9 простых правил:

1. Не занимайтесь спамом
2. Спрашивайте у адресатов согласия на рассылку
3. Обновляйте ваши базы адресов
4. Не используйте покупные базы
5. Храните подтверждения о законности вашей базы
6. Давайте возможность отписаться прямо из рассылки
7. Не повторяйтесь
8. Красиво и грамотно составляйте письма
9. Учитывайте требования спам-фильтров

Привет!

Пару месяцев назад я опубликовал на Хабре статью, посвященную описанию open-source проекта Centrifuge. Напомню, что это сервер рассылки сообщений подключенным клиентам (в основном из веб-браузера) в реальном времени. Написан на Python.

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

2 октября Яндекс уже в четвёртый раз проведёт YaC. Yet another Conference — это самая большая технологическая конференция в Европе. Ну, если не во всей Европе, то в Восточной — точно.



Последний раз я писал пост на Хабрахабр пять лет назад. И как раз пять лет назад мы задумывали YaC. Тогда мы чётко сформулировали для себя, что не хотим делать очередную маркетинговую конференцию про одну конкретную компанию Яндекс. Мы сделали мероприятие, которое вообще не про Яндекс. Для нас YaC — это огромная дискуссионная площадка.

Рассмотрены примеры таких конструкций + некоторые очевидные, но не менее опасные конструкции, которых в коде желательно избегать. Статья рассчитана на python программистов с опытом 0 — 1,5 года. Опытные разработчики могут в коментах покритиковать или дополнить своими примерами.

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

В июле мы вместе с ведущими IT-Kompot и релиз-инженерами Badoo Владиславом Черновым и Олегом Оямяэ записали выпуск подкаста «Процесс разработки и выкатка релизов в Badoo. Автоматическое тестирование. Девелоперское окружение».
Так как прошлый подкаст вызвал интерес у слушателей и читателей, то этот подкаст мы тоже превратили в статью.

О чем говорили:
Процесс разработки и выкатки релизов в компании Badoo. Используемые инструменты.

• GIT Workflow. Каждая задача в отдельной ветке;
• Использование JIRA, TeamCity и AIDA;
• Формирование релиза и выкатка двух релизов в день. Проблемы и их решения (откат, патчи и т.д.).

Автоматическое тестирование. Рецепт быстрого прогона большого количества тестов.

• Что мы используем;
• Как гоняем тесты;
• Code Coverage;
• Пускалка. 18000 тестов за 3,5 минуты.

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

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

Использование контейнера для каждого изображения

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

<div class="img_wrapper">
    <img src="comicbookguy.jpg" alt=""/>
</div>

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

Август 2013

(Это одно из двух эссе по фандрайзингу. Скоро выйдет следующее по тактике фандрайзинга.)

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

Инвесторы ищут стартапы, которые станут очень успешными. Легко сказать! В стартапах, как и в некоторых других областях, распределение стартапов по степени их успешности подчиняется степенному закону, только в стартапах кривая распределения ещё круче. Очень успешные стартапы настолько успешны, что затмевают собою все остальные. А поскольку число крупных успехов в год можно по пальцем пересчитать (есть мнение, что их в среднем 15 успешных стартапов в год), то инвесторы вообще смотрят на стартапы в черно-белых очках – либо у вас есть шанс стать одним из 15, либо нет.

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

На днях закрыли очередной проект. Суть: создание новой версии интернет-каталога. Старая версия сайта, в силу ряда причин, клиента не устраивала. Особенностью проекта была его номенклатурная база. Объём номенклатуры каталога составлял ~26000 позиций раскиданных по дереву из 513 узлов + характеристики товара. Почти каждая номенклатурная позиция имела описание на 1-2К текста.

Файл выгрузки каталога в формате ComerceML 2 для старого сайта весил 104 MB. Формировался на стороне 1С 10 минут и после передачи на хостинг, парсился на стороне сайта полтора часа (!) со 100% загрузкой CPU.

Как всё начиналось

Однажды мне пришлось участвовать в разработке одного небольшого проекта для научных расчётов, который разрабатывался на языке программирования Python. Изначально Python был выбран как удобный и гибкий язык для экспериментов, визуализации, быстрого прототипирования и разработки алгоритмов, но в дальнейшем стал основным языком разработки проекта. Надо заметить, что проект был хоть и не большим, но довольно насыщенным технически. Для обеспечения требуемой функциональности, в проекте широко применялись алгоритмы теории графов, математическая оптимизация, линейная алгебра и статистика. Также использовались декораторы, метаклассы и инструменты интроспекции. В процессе разработки пришлось использовать сторонние математические пакеты и библиотеки, например, такие как numpy и scipy, а также многие другие.

Со временем стало ясно, что переписывать проект на компилируемом языке слишком затратно по времени и ресурсам. Скорость работы и потребление памяти не являлись критичными показателями в данном случае и были вполне приемлемыми и достаточными. Поэтому было принято решение оставить всё как есть, и продолжить разработку и поддержку проекта на языке Python. К тому же, документация по большей части уже была написана с использованием Sphinx.

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

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

Некоторое время назад мы рассказывали на Хабре о том, что поиск Яндекса стал более персонализированным. Он учитывает не только постоянные, но и сиюминутные интересы пользователя, ориентируясь на последние несколько запросов и действий.

Сегодня мы хотим рассказать о технологии Real Time MapReduce, благодаря которой всё это стало возможно. Она обеспечивает передачу и обработку огромных объёмов данных, необходимых для этой задачи, и чтобы сделать это, нам даже не пришлось переписывать код для MapReduce, который у нас уже использовался.



Чтобы персонализировать поисковую выдачу, нужно определить круг интересов пользователя, для чего мы сохраняем информацию о его поведении на странице поиска. Данные о действиях пользователя записываются в логи, а затем обрабатываются при помощи специальных алгоритмов, которые позволяют нам составить наиболее релевантную выдачу по запросу для каждого отдельно взятого пользователя. Сначала обработка логов запускалась раз в сутки, для чего очень хорошо подходила технология распределенных вычислений MapReduce. Она прекрасно справляется с анализом значительных объемов данных.

Недавно я наткнулся на такую удивительную штуку как число Данбара.
История такова. 20 с лишним лет назад, когда выражение «британские учёные» ещё не было мемом, антрополог Робин Данбар, изучая данные по человекообразным обезьянам, обнаружил, что численность их стаи подчиняется определённому закону. Есть максимальное количество членов стаи. Если стая разрастается и её численность превышает порог, она разделяется на две. Причём для разных видов этот предельный размер получается разным.

Разрабатывая постоянно сталкиваешься с разнообразными задачами, которые часто решить в лоб не удаётся. Но многие задачи уже были решены кем-то — нужно только найти это решение.

Так, день за днём я насобирал небольшую коллекцию батареек, которые сильно облегчили мне жизнь. Чем и спешу поделиться:

Рассмотрим ситуацию: имеется статистическая таблица с колонками-идентификаторами и колонками-счётчиками. Требуется просуммировать счётчики по некоторому подмножеству. При этом нас не интересует, каким образом мы выбираем интересующее нас множество — про индексы и партицирование написано множество книг и статей. Будем считать, что все данные уже выбраны самым оптимальным способом и изучим, как быстрее суммировать.

Это не первое место, которое надо оптимизировать, если запрос тормозит, скорее последнее. Изложенные ниже идеи осмысленно применять когда план выполнения (explain) уже с виду идеальный и комар в нём носа не подточит, но хочется «выжать» ещё немного.

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

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

Для того чтобы пользователи, находясь офлайн, узнавали о событиях на сайте, мы создали специальную систему уведомлений. В её задачи входит аккумулировать события для пользователя и в нужный момент сообщать о них через доступные каналы связи, такие как электронная почта и push-уведомления на смартфоны.
Как организовано хранение событий? О каких событиях приходят уведомления? В какой момент они отправляются и по какому принципу? Сегодня мы постараемся ответить на все эти и другие вопросы.

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

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

В статье я опишу свой небольшой open-source проект — Centrifuge (далее Центрифуга). Это сервер на Python, задача которого — рассылка (broadcast) сообщений в реальном времени подключенным (в основном из браузера) клиентам.

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

Для начала, посмотрите, пожалуйста, скринкаст (не забудьте включить субтитры), если после просмотра интерес не пропадет, смело читайте дальше!