Сегодня внутренняя разработка компании Яндекс — аналитическая СУБД ClickHouse, стала доступна каждому. Исходники опубликованы на GitHub под лицензией Apache 2.0.



ClickHouse позволяет выполнять аналитические запросы в интерактивном режиме по данным, обновляемым в реальном времени. Система способна масштабироваться до десятков триллионов записей и петабайт хранимых данных. Использование ClickHouse открывает возможности, которые раньше было даже трудно представить: вы можете сохранять весь поток данных без предварительной агрегации и быстро получать отчёты в любых разрезах. ClickHouse разработан в Яндексе для задач Яндекс.Метрики — второй по величине системы веб-аналитики в мире.

В этой статье мы расскажем, как и для чего ClickHouse появился в Яндексе и что он умеет; сравним его с другими системами и покажем, как его поднять у себя с минимальными усилиями.

В 2014 году я выступил на открытии конференции GopherCon с докладом под названием «Go: Best Practices for Production Environments». В SoundCloud мы были одними из первых пользователей Go и к тому времени уже два года писали на нём и поддерживали Go в бою в той или иной форме. За это время мы кое-чему научились, и я попытался поделиться частью этого опыта.

С тех пор я продолжал программировать на Go в течение всего рабочего дня, сначала в командах SoundCloud, отвечающих за операционную деятельность и инфраструктуру, а теперь работаю в компании Weaveworks над Weave Scope и Weave Mesh. Также я усердно трудился над Go kit, набором инструментов для микросервисов с открытым исходным кодом. И всё это время я принимал активное участие в развитии сообщества Go-программистов, встречался со многими разработчиками на митапах и конференциях по всей Европе и в США, коллекционируя их истории успехов и провалов.

В ноябре 2015-го, на шестую годовщину релиза Go, я вспоминал то своё первое выступление. Какие из лучших практик прошли проверку временем? Какие из них устарели или стали неэффективными? Появились ли какие-то новые методики? В марте мне представилась возможность выступить на конференции QCon London, где я рассказал о лучших практиках 2014 года и дальнейшем развитии Go до 2016 года. В этом посте представлена выжимка из моего выступления.

Ключевые положения я выделил в тексте в виде Top Tips — лучших советов.

А вот и cодержание:

1. Среда разработки
2. Структура репозитория
3. Форматирование и стиль
4. Конфигурация
5. Разработка программы
6. Логирование и метрики
7. Тестирование
8. Управление зависимостями
9. Сборка и развёртывание
10. Заключение

Как-то раз, читая новости на Медузе, я обратил внимание на то, что у разных новостей разное соотношение лайков из Facebook и ВКонтакте. Какие-то новости мегапопулярны на fb, а другими люди делятся только во ВКонтакте. Захотелось присмотреться к этим данным, попытаться найти в них интересные закономерности. Заинтересовавшихся приглашаю под кат!

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

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

Данная заметка не открывает тайн вселенной и не устанавливает новых нравственных императивов. Однако, надеюсь, будет кому то полезна. Экзистенциальным толчком к написанию этой статью и осмыслению изложенных мыслей, для меня случился, когда одним прекрасным днём, мои мысли свернулись в черную дыру, от диких воплей технического директора, обсуждающего какие-то нерабочие моменты. Зародившуюся немного позже очередную звезду мыслительной деятельности, засосало туда же, после того как меня умудрились пнуть по коленке (сосед который сидит напротив). А добил ещё один коллега, почти сразу же ощутимо врезавшись в спинку моего кресла. Глядя на часы, показывавшие шесть часов вечера и глядя на свою продуктивность, хотелось плакать. Отчего же так? Я начал вспоминать, анализировать судьбинушку свою горькую и результатом данного анализа, и стала данная статья.

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

На прошлой неделе в компании Clarifai мы формально анонсировали нашу модель распознавания непристойного контента (NSFW, Not Safe for Work).

Предупреждение и отказ от ответственности. Эта статья содержит изображения обнажённых тел в научных целях. Мы просим не читать дальше тех, кому не исполнилось 18 лет или кого оскорбляет нагота.

---

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

Tarantool — NoSQL СУБД, которая разрабатывается и широко используется в Mail.Ru Group. Об объемах использования можно сделать вывод по публикациям:

• Под высокой нагрузкой: наши способы применения Tarantool
• Asyncio Tarantool Queue, вставай в очередь

Недавно Mail.Ru Group выпустила виртуальную машину с предустановленным Tarantool для Microsoft Azure:

• Tarantool on Microsoft Azure Marketplace
• Открытая БД Tarantool от Mail.Ru сертифицирована и размещена в Azure Marketplace

Мы решили проверить, насколько хорошо Tarantool работает в Microsoft Azure в сравнении с другими подобными предложениями — Azure Redis Cache, Bitnami Memcached, Aerospike и VoltDB. Под словом «хорошо» будем понимать «быстро», то есть сравнивать будем число обрабатываемых запросов в секунду (Throughput, RPS).

В мануале есть всё. Но чтобы его целиком прочитать и осознать, можно потратить годы. Поэтому один из самых эффективных методов обучения новым возможностям Postgres — это посмотреть, как делают коллеги. На конкретных примерах. Эта статья может быть интересна тем, кто хочет глубже использовать возможности postgres или рассматривает переход на эту СУБД.

В предыдущей статье о Центрифуге я рассказывал, что сервер был переписан с Python на Go (код Centrifugo на github, описание на opensource.mail.ru). C тех пор прошло несколько месяцев, за это время Центрифуга успела получить версию 1.0.0 и даже уйти немного дальше (последняя версия на момент этого поста — 1.4.2).

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

Уважаемые коллеги, у меня для вас отличные новости!

Открытая NoSQL-база данных Tarantool, которую разрабатывает компания Mail.ru, была сертифицирована для облачной плафтормы Azure и опубликована в Azure Marketplace для удобства и скорости развертывания.

Tarantool – это высокопроизводительный сервер приложений на базе Lua, интегрированный с NoSQL СУБД. База данных разрабатывается в виде открытого проекта под лицензией BSD компанией Mail.ru и сообществом разработчиков.

Крупнейшим кейсом использования Tarantool служит сама компания Mail.ru, которая с помощью этой БД обеспечивает работу 30 миллионов пользователей и 500 миллионов email в сутки. Другими пользователями Tarantool являются Badoo, Avito, Qiwi, Wallarm и так далее.

Подробнее о Tarantool вы можете узнать на официальном сайте http://tarantool.org/ и странице на Facebook https://www.facebook.com/TarantoolDatabase/.

В ноябре 2015 года мы вспоминали, как менялся интерфейс Аськи. Сегодня мы выпустили новую версию для Windows, внешность которой была полностью переработана. ICQ обрела минималистичный интерфейс и стала очень похожа на свою мобильную инкарнацию. А кроме того — тадам! — мы открыли исходный код приложения, потому что использовали для создания новой версии кроссплатформенный инструментарий Qt.

Введение

Прежде всего определимся с терминами. Есть много разных представлений о том, кто же такой full stack разработчик, кто-то даже вполне обоснованно считает, что такие разработчики — это миф, но в этой статье будет иметься в виду разработчик, который обладает знаниями и умениями, позволяющими с нуля написать некий софт и вывести его в продакшн. При этом софт может быть рассчитан на web платформу, мобильные приложения или десктопные. Идеальный full stack разработчик — это тот, кто владеет в какой-то мере всеми платформами и может разработать и установить на них свой софт. Но это действительно скорее миф.

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

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

К вашему сведению! В этой статье мы рассматриваем само явление docker-контейнеров, а не составляем список микросервисов, которые гнездятся внутри. Этим мы займемся в следующей серии, во имя справедливости!

UPDATE: пришлось заменить «докер» на «docker», иначе статья не ищется. Заранее прошу прощения за все «docker'ы» в тексте. Селяви.

Что мы имеем сегодня

• Зоопарк дубовых VPS-хостингов.
• Дорогие IaaS и PaaS с гарантированным vendor lock in.
• Уникальные сервера-снежинки.
• Ворох устаревших зависимостей на неподдерживаемой операционке.
• Скрытые связи частей приложения.
• Незаменимый админ полубог на скейтборде.
• Радуга окружений: development, testing, integration, staging, production.
• Генерация конфигов для системы управления конфигами.
• Feature flagging.
  

_{Фото: ivan dupont}

Всем привет! Меня зовут Дмитрий Исайкин, и с недавних пор я занимаюсь мобильной разработкой. Почему с недавних? Еще три месяца назад я был руководителем группы C/C++-разработки Почты Mail.Ru. Но однажды я в очередной раз задумался о том, что мне всё меньше и меньше нравится то, чем я занимаюсь. Больше времени стали отнимать обязанности тимлида: мотивация, стимуляция, отчётность, административные заботы. И тогда я решил: пора что-то менять. Разместил резюме, сходил на несколько собеседований. Всё это время я размышлял о том, чего же я хочу. Мне предложили возглавить направление разработки в одной достаточно крупной фирме, и я практически согласился. Но, «переспав» с этим решением бессонную ночь, я понял, что такая работа будет мне не в радость. Ещё был вариант пойти старшим разработчиком в другую хорошую фирму. Но там пришлось бы заниматься примерно той же работой, что и в предыдущие годы.

Я хотел бы подарить сообществу Хабра статью, в которой стараюсь дать достаточно полное описание подходов к алгоритмам подсчёта единичных битов в переменных размером от 8 до 64 битов. Эти алгоритмы относятся к разделу так называемой «битовой магии» или «битовой алхимии», которая завораживает своей красотой и неочевидностью многих программистов. Я хочу показать, что в основах этой алхимии нет ничего сложного, и вы даже сможете разработать собственные методы подсчёта единичных битов, познакомившись с фундаментальными приёмами, составляющими подобные алгоритмы.

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



Началось всё с того, что я заметил странную особенность CMS Wordpress. Так, при при первом обращении, к моему сайту по адресу www.domain.com/non_existent_file.ext выводился заголовок «404 Not Found», а при повторном «200 OK». На тот момент казалось, что на это могут влиять мои правки в движке и различные прикрученные костыли. Но при диагностике, на этапе отключения плагинов, выяснилось, что причиной такого поведения является плагин «W3 Total Cache». Не разбираясь в деталях, с мыслью «допилят ещё», включил его снова и забыл.

Через пару месяцев решил добавить этот сайт в Я.Вебмастер. Сервис предоставлял несколько способов для подтверждения владения сайтом.

Программы поиска уязвимостей всегда привлекают немало внимания со стороны хакеров и специалистов по безопасности. Ведь это легальный способ неплохо зарабатывать одними только поисками багов (при условии, что есть хороший опыт и голова на плечах). На днях нам представилась возможность взять интервью у багхантера Ивана reactors08 Григорова. Он лидер нашей программы Bug Bounty и занимает 11-е место в общем рейтинге платформы HackerOne.

Как начать искать баги? Может ли это быть единственным источником дохода? В каких Bug Bounty участвовать? Сколько зарабатывают багхантеры? И почему поиском уязвимостей особенно выгодно заниматься в кризис? Ответы на эти и другие вопросы читайте в нашем интервью.

Нечеткий поиск строк является весьма дорогостоящей в смысле вычислительных ресурсов задачей, особенно если вам необходима высокая точность получаемых результатов. В статье описан алгоритм нечеткого поиска в словаре, который обеспечивает высокую скорость поиска при сохранении 100% точности и сравнительно низком потреблении памяти. Именно автомат Левенштейна позволил разработчикам Lucene повысить скорость нечеткого поиска на два порядка

Раньше мы уже искали необычные модели Playboy с помощью библиотеки Python Scikit-learn. Теперь мы продемонстрируем некоторые возможности библиотек SymPy, SciPy, Matplotlib и Pandas на живом примере из разряда занимательных школьных задач по математике. Цель — облегчить порог вхождения при изучении Python библиотек для анализа данных.

Обработка запросов SQL и  в Оракле, и в Постгресе имеет много общего. Так или иначе, надо выполнить синтаксический разбор, проверить семантику (для чего потребуется метаинформация, и не важно, называется ли это «словарь данных» или «системный каталог»), выполнить какие-то преобразования, построить оптимальный план выполнения (в обеих системах основанный на стоимости, а следовательно требующий заранее собранной статистики).

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

В статье мы попытаемся проследить, как из-за разницы в одном архитектурном решении логически следует совершенно разная идеология работы в запросами в двух СУБД.

Приведенные примеры (которые выполнялись на версиях Oracle 11.2 XE и PostgreSQL 9.4) содержат время выполнения запросов. Нас интересуют только относительные величины: во сколько раз изменилось время выполнения после внесения в запрос тех или иных изменений. При этом абсолютные цифры могут отличаться на порядки в зависимости от аппаратуры, нагрузки и настроек. Чтобы не давать повод для бессмысленных выводов на их основании, все абсолютные значения в статье отмасштабированы так, чтобы один из запросов составлял в обеих системах 10 секунд.