KubeGraf — это плагин для Grafana, который собирает данные с кластера Kubernetes и приложений внутри него, а затем показывает их на красивых и понятных графиках. В феврале этого года вышел релиз 1.5, и стало известно, что предыдущие версии скачали более 250 тысяч раз! Мы расспросили Сергея Спорышева, создателя плагина и директора направления DevOps-продуктов в ITSumma, об истории создания плагина, факапах и причинах популярности.

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

В сети магазинов Светофор лампочки Экономка продаются за 38 рублей 80 копеек.
На лампе написано «15 Вт, заменяет 135 Вт, 1350 лм, Ra>80».

Я думаю вы уже догадываетесь, что всё это неправда.

Как приложение Cloud-Clout «засекречивает» файлы в публичных облаках

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

К примеру, туристы жалуются, что при въезде в Китай на их телефоны принудительно устанавливают приложение, которое сканирует все содержимое телефона. Правительства разных стран постоянно пытаются заставить операторов облачных хранилищ выдавать пользовательские данные спецслужбам даже без решения суда. Известный поборник приватности Павел Дуров только под большим общественным давлением разрешил полностью скрывать номера телефонов в своем мессенджере. А Эдвард Сноуден вообще не советует использовать WhatsApp и Telegram, если вам есть что скрывать.

ОК, для чатов можно использовать децентрализованный месенджер поверх e-mail. Но как быть с хранением и обменом файлами?

Машинное обучение занимается поиском скрытых закономерностей в данных. Растущий рост интереса к этой теме в ИТ-сообществе связан с исключительными результатами, получаемыми благодаря ему. Распознавание речи и отсканированных документов, поисковые машины — всё это создано с использованием машинного обучения. В этой статье я расскажу о текущем проекте нашей компании: как применить методы машинного обучения для увеличения производительности СУБД.
В первой части этой статьи разбирается существующий механизм планировщика PostgreSQL, во второй части рассказывается о возможностях его улучшения с применением машинного обучения.

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

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

Постановка вопроса

Недавно, во время собеседования в одну крупную компанию мне задали простой вопрос, что такое Load Average. Не знаю, на сколько правильно я ответил, но лично для себя пришло осознание, что точного ответа я на самом деле и не знаю.

Большинство людей наверняка знают, что Load Average — это среднее значение загрузки системы за некоторый период времени (1, 5 и 15 минут). Так же можно узнать некоторые подробности из данной статьи, про то, как этим пользоваться. В большинстве случаев этих знаний достаточно для того, что бы по значению LA оценивать загрузку системы, но я по специальности физик, и когда я вижу «среднее за промежуток времени» мне сразу становится интересна частота дискретизации на данном промежутке. А когда я вижу термин «ожидающие ресурсов», становится интересно, каких именно и сколько времени надо ждать, а так же сколько тривиальных процессов надо запустить, что бы получить за короткий промежуток времени высокий LA. И главное, почему ответы на эти вопросы не дает 5 минут работы с гуглом? Если вам данные тонкости так же интересны, добро пожаловать под кат.

Многие документы содержат защитные элементы, такие как голограммы, водяные знаки, гильош и т.д. В процессе сканирования таких документов возникает проблема — защитные элементы мешают системам распознавания (OCR). При разработке Smart PassportReader мы провели исследование, направленное на поиск и устранение подобных защитных элементов с изображений документов.

Рассмотрим пример паспорта гражданина РФ, на котором легко увидеть периодический голографический узор.



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

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

Современные компиляторы очень хорошо умеют оптимизировать код. Они удаляют никогда не выполняющиеся условные переходы, вычисляют константные выражения, избавляются от бессмысленных арифметических действий (умножение на 1, сложение с 0). Они оперируют данными, известными на момент компиляции.
В момент выполнения информации об обрабатываемых данных гораздо больше. На её основании можно выполнить дополнительные оптимизации и ускорить работу программы.
Оптимизированный для частного случая алгоритм всегда работает быстрее универсального (по крайней мере, не медленнее).
Что если для каждого набора входных данных генерировать оптимальный для обработки этих данных алгоритм?
Очевидно, часть времени выполнения уйдёт на оптимизацию, но если оптимизированный код выполняется часто, затраты окупятся с лихвой.
Как же технически это сделать? Довольно просто — в программу включается мини-компилятор, генерирующий необходимый код. Идея не нова, технология называется “компиляция времени исполнения” или JIT-компиляция. Ключевую роль JIT-компиляция играет в виртуальных машинах и интерпретаторах языков программирования. Часто используемые участки кода (или байт-кода) преобразуются в машинные команды, что позволяет сильно повысить производительность.
Java, Python, C#, JavaScript, Flash ActionScript — неполный (совсем неполный) список языков, в которых это используется. Я предлагаю решить конкретную задачу с использованием этой технологии и посмотреть, что получится.

Вступление

Давно хотел написать статью про образование в Computer Science, но руки не доходили. Решил все-таки это наконец сделать. Итак, о чем пойдет речь? Речь о том, что из себя представляет диплом MSc Computer Science топовых университетов США (во всех подробностях, включая основные курсы, книги и проекты) и как ему соответствовать.

Почему именно MSc? Это — некая развилка: с одной стороны после MSc — вы уже готовый к жизни инженер (да, речь идет о инженерной подготовке, как мне кажется это самое больное место в нашей системе образования), с другой — можно спокойно идти по пути PhD. Как известно, в PhD программу можно попасть и не особо умея программировать — особенно это касается теоретического Computer Science. С другой стороны найти работу программиста тоже дело не очень сложное, и часто не требует мощного образования. Но достигнув уровня MSc — вы получаете возможность разбираться как во всех новый идеях в Computer Science, так и возможность их воплотить в практику. То есть с одной стороны круто разобраться в каком-нибудь deep learning и сделать в нем что-то новое, а также взять и написать свою операционную систему (кто так сделал?). Причем вы не зажаты в рамки узкой специализации (если конечно продолжаете учиться). То есть вы теперь — универсальный солдат, готовый на все.

Надеюсь что эта статья будет полезна:
1. Студентам, которые хотят соответствовать высоким стандартам топ вузов США, или собирающиеся туда в аспирантуру по Computer Science
2. Профессионалам, которые хотят закрыть «дыры» и пробелы
3. Может кто-то из преподавателей возьмет на заметку для своих курсов.
4. Студентам, аспирантам американских вузов — хотелось бы тоже получить фидбэк, особенно касается последних трендов в образовании

Что же здесь будет написано? Минимум философии и общих мыслей: конкретная программа undergraduate и graduate курсов, конечно из дисциплин наиболее мне близких. Все курсы были лично прочувствованы на собственной шкуре, по этому и пишу. (Я пытался записаться на все интересные курсы, которые были, но мой основной упор — системное программирование, базы данных и искусственный интеллект. Отсюда конечно некий bias, но пытаюсь предложить более-менее универсальную программу).

^{Тестовый прогон}

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

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

По информации СМИ, Facebook справился с угрозой и заблокировал распространение вредоносных сообщений. Однако позже мы обнаружили дальнейшее распространение ряда вредоносных ссылок и решили разобраться в том, как работает эта атака, чтобы защитить от неё пользователей Яндекс.Браузера.

СМИ сообщали, что виной всему было вредоносное расширение YouTurn для браузера Chrome, которое пользователю предлагалось установить, если он переходил по ссылке, полученной от своего зараженного друга. Но мы выяснили, что в рамках этого заражения использовалось несколько расширений. YouTurn, кстати, 16 декабря уже было удалено из ChromeStore.



Все они были одинаково устроены, но распространялись под разными названиями и в разное время через фишинговые ресурсы, похожие на страницу Facebook и размещённые на Amazon S3. Интересно, что помимо механизмов распространения они подгружали во все вкладки браузера рекламные баннеры с сомнительным содержимым и предоставляли доступ к аккаунту зараженного пользователя внутреннему приложению с некоторым ID, которое Facebook тоже заблокировал.

Итак, таким ли безобидным был этот «вирус», и что в нём было нового?

Все началось с данного топика на сайте gamedev.ru. Топикстартер предложил найти сортировку, которая обладает следующими свойствами:

1. Время выполнения — гарантированные O(nlogn).
2. Использование O(1) дополнительной памяти.
3. Применимость для сортировки данных в односвязных списках (но не ограничиваясь ими).

Оговорки на все три ограничения:

1. Гарантированные O(nlogn) означают, что, например, среднее время быстрой сортировки не подходит — должно получаться O(nlogn) для любых, даже самых худших входных данных.
2. Рекурсию использовать нельзя, поскольку она подразумевает O(logn) памяти на хранение стека рекурсивных вызовов.
3. Произвольного доступа к элементам сортируемого массива нет, мы можем двигаться итератором от любого элемента только к соседнему (за O(1)), причем только в одном направлении (вперед по списку). Модифицировать сам список (перевешивать указатели на следующие элементы) нельзя.

Вся информация, которую мы знаем об элементах массива — это то, что они все образуют линейно упорядоченное множество. Все, что мы можем делать — это сравнивать два элемента массива (за O(1)) и менять их местами (тоже за O(1)).

Под катом можно узнать, что в итоге получилось у нас.

Challenge. Прежде чем заглядывать под кат, предлагаю сначала самостоятельно подумать над алгоритмом. Если придумается что-то круче нашего варианта — напишите в комментариях.

Разработчики сегодня создают новые классы приложений. Эти приложения разрабатываются уже не под отдельный сервер, а запускаются с нескольких серверов в дата-центре. Примеры включают фреймворки, реализующие аналитические вычисления, такие как Apache Hadoop и Apache Spark, брокеров сообщений, вроде Apache Kafka, key-value хранилища, например Apache Cassandra, а также приложения, с которыми работают непосредственно конечные пользователи, вроде тех, которые используются компаниями Twitter и Netflix.

Эти новые приложения – больше, чем просто приложения, это – распределенные системы. Точно так же, как когда-то для разработчиков стало привычным создавать многопоточные приложения для отдельных машин, становится общепринятым проектировать распределенные системы для дата-центров.

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

Компания, где я работаю, разрабатывает программное обеспечение на C++ под Linux. Долгое время мы использовали Qt Creator, с редкими ребятами работающими из Emacs и Vim. Когда я сам попытался пересесть на Vim, я понял, что ситуация с плагинами для разработки на С++ очень не простая. Поработав немного с CTags, я быстро понял, что без напильника работать в Vim будет очень сложно.
К сожалению, с ростом опыта работы с Vim редактор в Qt Creator в режиме эмуляции устраивал меня все меньше, и в какой-то момент я решил потратить немного времени и разобраться, как же сделать из Vim нормальную среду.
Я очертил для себя четыре вещи, которые я бы хотел от среды разработки, и которых мне бы хватило в Vim, чтобы полностью на него перейти:

1. Автодополнение
2. Навигация по коду
3. Отладка прямо из среды
4. Интеграция с Git (в частности Blame прямо в редакторе, и Git Grep)

Автодополнение в Vim — это решенная проблема, и название у решения YouCompleteMe. Это очень качественный плагин, который реализует автодополнение для большого количества языков программирования, в частности Python и C++. Ходят слухи, что внутри Google YouCompleteMe решает и вторую проблему с навигацией кода, но использует для этого внутренные инструменты гугла для индексирования.

Интеграция с Git в какой-то степени решена с помощью vim-fugitive. Это не такая комплексная интеграция, как бывает у Jet Brains, или в Visual Studio, но сравнимая с тем, что предлагает Qt Creator. Те два сценария, которые нужны были мне: blame и grep — работают хорошо.

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

Сегодня мы рассмотрим алгоритм TILT (Transform Invariant Low-rank Texture) и множество его методов применения в области Computer Vision. Статья будет нести несколько обзорный характер, без плотного углубления в математические дебри.

Со времени предыдущего поста из жизни lock-free контейнеров прошло немало времени. Я рассчитывал быстро написать продолжение трактата об очередях, но вышла заминка: о чем писать, я знал, но реализации на C++ этих подходов у меня не было. «Не годится писать о том, что сам не попробовал», — подумал я, и в результате я попытался реализовать в libcds новые алгоритмы очередей.
Сейчас настал момент, когда я могу аргументированно продолжить свой цикл. В данной статье закончим с очередями.

Кратко напомню, на чем я остановился. Были рассмотрены несколько интересных алгоритмов lock-free очередей, а под занавес приведены результаты их работы на некоторых синтетических тестах. Главный вывод — всё плохо! Надежды на то, что lock-free подход на магическом compare-and-swap (CAS) даст нам пусть не линейный, но хотя бы какой-то рост производительности с увеличением числа потоков, не оправдались. Очереди не масштабируются. В чем причина?..

В детстве я не расставался с конструкторами. У меня их было 2 типа: аналог LEGO (пластмассовый и с пупырышками) и металлический с болтиками. После поста на Хабре, я понял, насколько скудный был в те времена выбор. Пару недель назад мембер хакспейса Костя Костюк подсказал мне, что в Москве есть люди, которые занимаются продвижением и обучением FISCHERTECHNIK.


(на фото: Электромобиль с заправочной станцией и водородный топливный элемент, солнечная батарея)

В Германии вокруг этого конструктора сложилось свое сообщество, они гордятся своим изобретателем и ставят свои рекорды.

Чем понравился мне этот конструктор — хардкорностью научно-технической серьезностью и отсылками ко множеству реальных механизмов/устройств (от принтера, CD-привода и механизмов Леонардо да Винчи, до шаговых экскаваторов, роботов и электромобилей). В наборы входит и контроллер с графической средой программирования, что позволяет учить детей основам алгоритмов и программирования.

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


(Осторожно! Под катом боль за бесцельно прожитые годы)

Перевод статьи Джефа Прешинга Atomic vs. Non-Atomic Operations. Оригинальная статья: http://preshing.com/20130618/atomic-vs-non-atomic-operations/

В Сети уже очень много написано об атомарных операциях, но в основном авторы рассматривают операции чтения-модификации-записи. Однако, существуют и другие атомарные операции, например, атомарные операции загрузки (load) и сохранения (store), которые не менее важны. В этой статье я сравню атомарные загрузки и сохранения с их неатомарными аналогами на уровне процессора и компилятора C/C++. По ходу статьи мы также разберемся с концепцией «состояния гонок» с точки зрения стандарта C++11.