Техники перехвата функций в Linux хорошо известны и описаны в интернете. Наиболее простой метод заключается в написании динамической библиотеки с «функциями-клонами» и использовании механизма LD_PRELOAD для переопределения таблицы импорта на этапе загрузки процесса.

Недостаток LD_PRELOAD в том что необходимо контролировать запуск процесса. Для перехвата функций в уже работающем процессе или функций отсутствующих в таблице импорта можно использовать «сплайсинг» — запись команды перехода на перехватчик в начало перехватываемой функции.

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

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

Так или иначе, практически каждый из нас использовал в своей жизни технику интеллект–карт или Mind Mapping. Это всего лишь простая радиальная схема, но с правильным подходом ее можно превратить в мощный инструмент аналитики и синтеза информации, который всегда под рукой и достаточно прост в использовании. И что самое интересное, освоение техники настолько естественно для нашего мозга, что занимает всего лишь несколько минут…

Полагаю, все мы однажды искали себе жилье. Кто-то — в собственность, большинство, вероятно, в аренду. Все, кто хоть раз пытался найти реальные предложения на досках объявлений, знают — это нереально. Такого количества спама нет, пожалуй, ни в одной другой сфере. После того, как окунешься в этот ад, обычно руки начинают чесаться применить свою IT-шность на благо ближнему. Результатом для меня стал проект Sobnik, о котором я и хочу рассказать.

Sobnik — это плагин для Chrome, который помечает посредников на досках объявлений. Пока работает только с Avito.ru, в ближайшем будущем я добавлю Irr.ru и другие крупные доски. Всех, кто сидит на чемоданах и кому не терпится попробовать, прошу в Google Web Store. Под катом я расскажу о технической стороне проекта, о его перспективах и о моих наблюдениях за противником посредниками. Любители критиковать чужой JS-код также велкам, исходник клиентской части плагина доступен на github.

Пусть мы хотим вычислить десятимиллионное число Фибоначчи программой на Python. Функция, использующая тривиальный алгоритм, на моём компьютере будет производить вычисления более 25 минут. Но если применить к функции специальный оптимизирующий декоратор, функция вычислит ответ всего за 18 секунд (в 85 раз быстрее):


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

Эта статья расскажет о том, в каких случаях и каким образом декоратору удаётся делать подобные оптимизации. Также вы сможете сами скачать и протестировать библиотеку cpmoptimize, содержащую данный декоратор.

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

На этой неделе я начал читать бакалаврам Академического университета базовый курс по алгоритмам. Начинал я совсем с основ, и чтобы тем, кто с базовыми алгоритмами уже знаком, было чем заняться, я в начале пары сформулировал две, наверное, самые свои любимые задачки по алгоритмам. Давайте и с вами ими поделюсь. Решение одной из них даже под катом подробно расскажу. Но не отказывайте себе в удовольствии и не заглядывайте сразу под кат, а попытайтесь решить задачи самостоятельно. Обещаю, что у обеих задач есть достаточно простые решения, не подразумевающие никаких специальных знаний по алгоритмам. Это, конечно, не означает, что эти решения просто найти, но после пары один из студентов подошёл и рассказал правильное решение первой задачи. =) Если же вам интересно посмотреть на начало курса или порешать больше разных задач — приходите к нам на (бесплатный) онлайн-курс, который начнётся 15 сентября.

Задача 1. Дан массив A длины (n+1), содержащий натуральные числа от 1 до n. Найти любой повторяющийся элемент за время O(n), не изменяя массив и не используя дополнительной памяти.

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

Задача 2. Дана матрица nxn, содержащая попарно различные натуральные числа. Требуется найти в ней локальный минимум за время O(n).

Локальным минимумом матрицы называется элемент, который меньше всех своих четырёх соседей (или трёх, если этот элемент лежит на границе; или двух, если это угловой элемент). Обратите внимание, что от нас требуется линейное по n время, хотя в матрице квадратичное по n число элементов. Поэтому мы предполагаем, что матрица уже считана в память. И нам нужно найти в ней локальный минимум, обратившись лишь к линейному количеству её ячеек.

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

Перевод поста Стивена Вольфрама (Stephen Wolfram) "Computational Knowledge and the Future of Pure Mathematics"
Выражаю огромную благодарность тем, кто помог мне сделать этот перевод: Владиславу Глаголеву (Himura), Илье Марчевскому, Сергею Шевчуку (opckSheff) и Анне Коваленко.

Введение

Уже больше века, каждые 4 года в некоторой точке мира проходит Международный конгресс математиков (ICM). В 1900 году, именно на нем Давид Гильберт представил свою знаменитую коллекцию проблем математики, которая по сей день задает направление исследования математикам всего мира.

В этом году ICM проходит в Сеуле, и сегодня я отправляюсь туда. Однажды я уже бывал на ICM — в Киото в 1990 году. Тогда системе Mathematica было всего 2 года, и математики ещё только начинали привыкать к ней. Многие уже повсеместно её использовали, но на ICM были и те, кто говорил «Я занимаюсь чистой математикой. В чем, интересно, мне может помочь система Mathematica?»

Привет. Меня зовут Степан Кольцов. Недавно я выступал на Java Party в киевском офисе Яндекса с докладом про язык Rust, который несёт в себе очень много для будущего программирования. Некоторые коллеги утверждают, что я всегда говорю про Rust, когда у меня есть такая возможность. Сегодня я хочу поделиться этим рассказом с вами и объяснить, почему мне это кажется важным.



Для начала пара слов о том, что такое Rust. Последние 15 лет между разработчиками на Java и на C++ ведётся спор о том, какой язык программирования хуже — Java или C++. Программы на C++ глючат, падают, и в них утекает память. Программы на Java тормозят и требуют слишком много памяти.

Rust — новый современный язык программирования, разрабатываемый компанией Mozilla — решает проблемы Java и C++: программы, написанные на Rust, одновременно быстрые и безопасные. Rust является таким же низкоуровневым (в смысле close-to-metal) языком программирования, как и C++, однако в язык встроены конструкции, позволяющие на этапе компиляции доказывать, что в программе не случатся ошибки работы с памятью, как то обращение после использования, двойное удаление, использование неинициализированной памяти и т.п. В Rust для этого используется механизм borrowed pointers. Большая часть моего рассказа была посвящена описанию этого механизма.

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

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

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

Вот прямо сейчас кончаются времена, когда многие делали форменную туфту для получения лёгких денег по аналогу бума доткомов. И заявляли, что «начнём мы, когда найдем инвестора». Модель была простая: бралась идея с потолка, по ней ничего не делалось, но находился инвестор. По возможности — лох, не особо смыслящий в IT. Полученные деньги вкладывались в прототип и массу пиара, затем разыскивался инвестор второго раунда. Дальше стандартно: «когда водка выпита, выясняется, что джип разбит…». И проект заканчивался.

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

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

Разработка ПО – область, подверженная рискам. В нашей сфере при наступлении одного или нескольких рисков, срок поставки рабочей версии может сдвинуться не на привычные и комфортные 10-20%, а на все 150-300%. И надо признаться, что это далеко не предел.

Мы можем либо скрестить пальцы и надеяться, что удача будет сопутствовать проекту во всем, либо признать, что по статистике большая часть проектов по разработке ПО «проваливается» и предпринять дополнительные усилия по ослаблению возможных рисков.
Моя практика показывает, что клиенты крайне неохотно работают по схеме T&M и чаще предпочитают Fixed Price. В условиях зафиксированной стоимости наступление рискового случая означает автоматическое снижение рентабельности проекта: сотрудники получают зарплату ежемесячно, а не за сданные проекты.

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

Почему об этом следует думать разработчику, если есть менеджер?

1. Не секрет, что если факап случится, менеджмент примет единственное «супер-умное» решение: «давайте поработаем сверхурочно и в выходные»
2. Премии сотрудники получают тоже обычно за в срок сданные, а не за проваленные проекты
3. Чувство сделанного дела, в конце концов. Гораздо приятнее сдать проект во время и видеть улыбку клиента, чем с опозданием в полгода отвязаться от «трудного ребенка»

С моей точки зрения спокойная рабочая обстановка вместо авралов и бонусы – неплохая мотивация, чтобы начать заботиться об этом.

Обсуждение начну с весьма печального твита Криса Аллена (Chris Allen, @bitemyapp):

«Мне немного грустно от того, что некоторые организации твердят мантру „Вы сможете использовать haskell“, чтобы заполучить толковых инженеров подешевке».

— Untyped is unsane ( @bitemyapp) 3 июня 2014 г.

Для тех, кто не знает: Haskell — продуктивный и мощный язык, позволяющий программистам, по крайней мере талантливым, быстро писать правильный код. По сравнению с разработкой на Java скорость возрастает в 2–5 раз при сопоставимой производительности и меньшем количестве ошибок. Крис совершенно верно заметил, что разработчик, использующий Haskell, чаще всего не получает достойного вознаграждения. Если вы твердо решили использовать функциональное программирование, то будете зарабатывать меньше коллег, которые разгребают базы кода C++ в банках, накопленные за 30 лет. Как-то это все неправильно. Почему к программистам, применяющим более мощные инструменты, применяются экономические санкции? В отличие от управленцев, ставящих во главу угла выгоду, программисты действительно хотят сделать свою работу как можно лучше. Почему же вместо «пряника» за благие намерения они получают «кнут»?

В начале 2012 года по интернету гуляла видеозапись доклада Гарри Бернхардта на CodeMash под названием «WAT». На хабре были даже две хабрастатьи об этом докладе: раз, два. В этом выступлении рассказывалось про некоторые тонкости Ruby и JavaScript, которые кажутся нелогичными и вызывают реакцию: «WAT?».

В этой же хабрастатье я собрал десять примеров математических рассуждений, которые наоборот, на первый взгляд кажутся логичными, но видя полученный результат, также хочется задастся вопросом «ШТА?!!».

Итак, сможете определить где подвох?

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

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

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

Вид на City, сердце деловой Великобритании

Перед тем как перейти «на контракт» я работал в постоянным сотрудником в Лондоне в небольшой (700 серверов / 8 коллег) компании. Моя специализация — Wintel engineer, то есть я могу работать к в суппорте так и в техподдержке проектов. Все что связано с продуктами Microsoft. Я подумывал об уходе с постоянной работы, однако волею судеб пришлось уйти совершенно неподготовленным. Именно отсюда начинается мой рассказ о контрактниках в Великобритании.

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



Масла в огонь подливают Apple и Google. Эти просто скупают таланты на корню, на инвестиции не размениваясь. Первая недавно отчиталась о 29 приобретенных компаниях, ее главный конкурент число скупленных активов не раскрыл, но потраченную за полгода на покупки сумму назвал – $4.2 миллиарда.

1 августа в офисе Яндекса, открывшемся недавно в Берлине, состоялся финал нашего чемпионата по программированию. И его победителем снова стал известный всем, кто интересуется спортивным программированием, Геннадий Короткевич.

Задания для Алгоритма готовила международная команда. В нее вошли программисты из России, Беларуси, Польши и США. Это специалисты МГУ имени М.В. Ломоносова, Университета Карнеги-Меллон, сотрудники Яндекса и Google. В Яндексе задачи составляли разработчики минского и киевского офиса, а потом проверяли их на своих коллегах. Один из составителей в прошлом году сам был финалистом Алгоритма. Специально для Хабрахабра мы разобрали с авторами все задачи. Кстати, несмотря на то, что соревнование завершено, вы можете попробовать себя в вирутальном контесте.



На победу претендовали многие финалисты. Среди них были победители и призеры АСМ ICPC и TopCoder Open, разработчики Google и Facebook. В финальном раунде сражались призёры Алгоритма-2013 Евгений Капун и Ши Бисюнь, чемпион АСМ ICPC Михаил Кевер, а также один из самых титулованных спортивных программистов мира Пётр Митричев. В этом году побороться за приз решил также Макото Соэдзимо — составитель заданий для Алгоритма-2013 и администратор TopCoder Open.

Борьба за первое место разгорелась между Геннадием Короткевичем и Хосакой Кадзухиро из Токийского университета. Лучший результат — четыре задачи при 66 минутах штрафного времени — показал Короткевич, подтвердив титул чемпиона. Кадзухиро решил столько же задач, но набрал больше штрафного времени (90 минут) и занял второе место. Третье место завоевал Ван Циньши из университета Цинхуа: он решил четыре задачи при 125 минутах штрафа.

Привет! Меня зовут Роман Гущин. В Яндексе я занимаюсь ядром Linux. Некторое время назад я провел для системных администраторов семинар, посвященный общему описанию подсистемы управления памятью в Linux, а также некоторым проблемам, с которыми мы сталкивались, и методам их решения. Большая часть информации описывает «ванильное» ядро Linux (3.10), но некоторая часть специфична для ядра, использующегося в Яндексе. Вполне возможно, семинар окажется интересен не только системным администраторам, но и всем, кто хочет узнать, как в Linux устроена работа с памятью.



Основные темы, затронутые на семинаре:

• Задачи и компоненты подсистемы управления памятью;
• Аппаратные возможности платформы x86_64;
• Как описывается в ядре физическая и виртуальная память;
• API подсистемы управления памятью;
• Высвобождение ранее занятой памяти;
• Инструменты мониторинга;
• Memory Cgroups;
• Compaction — дефрагментация физической памяти.

Под катом вы найдете более подробный план доклада с раскрытием основных понятий и принципов.

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