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

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

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

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

Прошло уже больше года после завершения конкурса "Интернет-математика: Яндекс.Карты", но нас до сих пор спрашивают об алгоритме, который принёс нам победу в этом конкурсе. Узнав о том, что недавно Яндекс объявил о старте очередной "Интернет-математики", мы решили поделиться опытом нашего прошлогоднего участия и описать наш подход. Разработанный алгоритм смог с точностью 99.44% правильно определить лишние изображения в сериях панорамных снимков, например, как здесь:



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

Исходный код нашего решения доступен на github (C++ с использованием OpenCV).

Каждый месяц на Яндексе поиском по картинкам пользуется больше 20 миллионов человек. И если кто-то из них ищет фотографии [Мэрилин Монро], это не значит, что им нужно найти лишь самые знаменитые снимки актрисы. В такой ситуации результаты, в которых большая часть найденных изображений будет копиями одних и тех же картинок, вряд ли устроят пользователей. Им придётся пролистать большое количество страниц, чтобы увидеть разные фотографии Монро. Для того чтобы облегчать людям подобные задачи, нам нужно сортировать картинки в результатах поиска так, чтобы они не повторялись. И мы научились «раскладывать их по полочкам».



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

Не так давно Скотт Майерс (англ. Scott Meyers) — эксперт по языку программирования C++, автор многих известных книг — опубликовал статью, описывающую подробности использования rvalue ссылок в C++11.
На Хабре эта тема еще не поднималась, и как мне кажется, статья будет интересна сообществу.
Оригинал статьи: «Universal References in C++11—Scott Meyers»

«Универсальные» ссылки в C++11

T&& не всегда означает “Rvalue Reference”

Автор: Scott Meyers

Возможно, наиболее важным нововведением в C++11 являются rvalue ссылки. Они служат тем фундаментом, на котором строятся «семантика переноса (англ. move semantics)» и «perfect forwarding». (Вы можете ознакомится с основами данных механизмов в обзоре Thomas’а Becker’а).

Синтаксически rvalue ссылки объявляются также, как и «нормальные» ссылки (теперь называемые lvalue ссылками), за исключением того, что вы используете два амперсанда вместо одного. Таким образом, эта функция принимает параметр типа rvalue-reference-to-Widget:

void f(Widget&& param);

Учитывая, что rvalue ссылки объявляются с помощью “&&”, было бы разумно предположить, что присутствие “&&” в объявлении типа указывает на rvalue ссылку. Но это не так:

Widget&& var1 = someWidget;         // здесь “&&” означает rvalue ссылку

auto&& var2 = var1;                 // здесь “&&” НЕ означает rvalue ссылку

template<typename T>
void f(std::vector<T>&& param);     // здесь “&&” означает rvalue ссылку

template<typename T>
void f(T&& param);                  // здесь “&&” НЕ означает rvalue ссылку

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

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

Активные модели внешнего вида (Active Appearance Models, AAM) — это статистические модели изображений, которые путем разного рода деформаций могут быть подогнаны под реальное изображение. Данный тип моделей в двумерном варианте был предложен Тимом Кутесом и Крисом Тейлором в 1998 году [1]. Первоначально активные модели внешнего вида применялись оценки параметров изображений лиц, но затем они стали активно применяться и в других областях, в частности, в медицине при анализе рентгеновских снимков и изображений, полученных с помощью магнито-резонансной томографии.




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

Многие современные алгоритмы компьютерного зрения строятся на основе детектирования и сопоставления особых точек визуальных образов. По этой теме было написано немало статей на хабре(например SURF, SIFT). Но в большинстве работ не уделяется должного вниманию такому важному этапу, как фильтрация ложных соответствий между изображениями. Чаще всего для этих целей применяют RANSAC-метод и на этом останавливаются. Но это не единственный подход для решения данной задачи.
Данная статья посвящена одному из альтернативных способов фильтрации ложных соответствий.

Введение

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

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

Говоря «хаос», мы, обычно, подразумеваем полное отсутствие порядка, абсолютную неупорядоченность и случайность. С математической точки зрения, хаос и порядок – понятия не взаимоисключающие. Теория хаоса (есть что-то завораживающие в названиях математических теорий) – достаточно молодая математическая область, создание которой приравнивают по значимости открытий ХХ века к созданию квантовой механики. Хаос случается в нелинейных динамических системах. Иначе говоря, любой процесс, который протекает со временем, может быть хаотичным (например, высота дерева, температура тела или популяция мадагаскарских тараканов).

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

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

Часть 1. Хороший кодер != хороший работник

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

Недавно открыл для себя StrictMode, прочитав статью на Android Developers Blog. Ниже представляю Вам ее перевод.

За сценой

Одна из клевых вещей в Google — это «20% времени»: 20% от своего рабочего времени вы имеете право заниматься проектами, не имеющими никакого отношения к вашему основному проекту. Когда я пришел в Google, я постоянно переключался с проекта на проект и часто шутил по этому поводу, что у меня 7 таких 20%-ных проектов. Один из проектов, к которому я постоянно возвращался, был Android. Мне нравилась открытость платформы, которая давала мне возможность делать все, что я хотел, в том числе открывать двери моего гаража, когда я подъезжал к своему дому на мотоцикле. Я действительно хотел, чтобы этот проект был успешным, но я беспокоился об одном: Android никогда не был быстрым. Подтормаживающие анимации и элементы пользовательского интерфейса, которые не всегда сразу реагируют на ввод данных. Было очевидно, что причина этого — задачи, выполняющиеся не в том потоке.

Я являюсь активным пользователем SMS и одним из моих 20%-ных проектов в ходе подготовки релиза Cupcake (Android 1.5) стала оптимизация приложения обмена сообщениями. Я оптимизировал его и сделал более плавным, а затем продолжил метаться между другими своими 20%-ными проектами. После выхода релиза Donut (Android 1.6), я заметил, что некоторые из моих оптимизаций случайно оказались сломанными. Мне было немного обидно, но затем я понял, что Android действительно всегда не хватало, так это готового к использованию, встроенного, всепроникающего средства мониторинга производительности.

Я присоединился к команде разработчиков Android на полный рабочий день чуть более года назад и провел много времени за исследованиями проблем производительности во Froyo. В частности посвятил много времени борьбе с ANR-диалогами (вы видите эти раздражающие диалоги, когда приложение выполняет длительные операции внутри основного UI потока). Отладка этих диалогов, с помощью имеющихся инструментов, была трудной и утомительной. Их было не достаточно чтобы найти причину, особенно, при взаимодействии нескольких процессов (например, обращения из Binder'ов или ContentResolver'ов к Service'ам или ContentProvider'ам в других процессах). Необходим был более совершенный инструмент для отслеживания притормаживаний интерфейса или ANR-диалогов.

Почитал я статьи уважаемых авторов, и решил написать кое-что от себя. Что меня сподвигло на это? Не знаю, скорее желание поделиться своим опытом и какими-то конкретными примерами из жизни.
Так что еще, кроме активов, пассивов и всего уже описанного?

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

Уважаемые читатели!
Как психолог я чувствую необходимость и считаю своим долгом вселить веру в IT-специалистов и поделиться своим видением назревших проблем. В начале XXI столетия без ваших способностей и ваших идей сложно будет обойтись. Очевидно, что виртуальная информационная сеть растет и совершенствуется с огромной скоростью по всему миру, расширяет возможности развития и существования общества в целом, но и накладывает все новые и новые поведенческие шаблоны. Развитие компьютерных технологий – хороший бизнес, как за рубежом, так и в Украине. Одно только смущает: где же во всем этом процессе человек? Да-да, обычный программист, а есть ли среди них «обычные»? А дальше о главном и коротко.

Думаю, многие разработки знакомы с понятием code review или обзор кода по-русски (также данный термин переводят как просмотр кода, инспектирование кода или рецензирование кода – далее, для единообразия, будет использоваться вариант «обзор кода»). Недавно я столкнулся с необходимостью «разложить по полочкам» и классифицировать знания по этой теме. Результат – данная статья. Надеюсь, она окажется полезной, а также поможет внедрить обзоры кода в свой производственный процесс тем, кто только об этом задумывается.

Обзор кода является одним из наиболее эффективных методов поиска и устранения дефектов программы. Обзоры проводятся человеком, что позволяет находить широкий класс ошибок, в том числе с трудом детектируемых или вообще не детектируемых автоматическими средствами. Безусловно, обзор кода, не отменяет использование анализаторов кода или других методик обнаружения ошибок, например, unit-тестирования. К сожалению, не существует метода, который один обеспечил бы обнаружение всех дефектов программы (в исследованиях эффективность обзора кода обычно оценивается как 30-50% обнаруженных ошибок в приложении).

За двадцать лет разнообразного программирования я сформулировал, убежден, главнейший принцип хорошего кода. Опираясь на него, мне и моим коллегам удавалось приводить в порядок самый страшный код, объединять в команде малосовместимых программистов и годами поддерживать системы без лишнего нытья.

Прочтение этой статьи: 15 минут
Осмысление методики: 10 минут
Ощутимые результаты: 30 минут

В этой серии постов мы попробуем решить одну простую задачу с помощью более-менее актуальных технологий параллельного программирования (Нативные потоки, OpenMP, TBB, MPI, CUDA, OpenCL, OpenACC, Chapel может быть еще что-нить экзотическое. Как бы сравнительно и в hands-on ключе.

Оригинальная статья Джона Грэхем-Камминга.
Переведено и опубликовано с разрешения автора.

Я занимаюсь программированием уже более 30 лет, начиная с машин, уже устаревших (на процессорах Z80 и 6502) до современных, используя языки BASIC, ассемблера, C, C++, Tcl, Perl, Lisp, ML, occam, arc, Ruby, Go и многие другие.

Далее следует список того, чему я научился.

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

• «Программирование на КОБОЛе калечит мозг, поэтому обучение ему должно трактоваться как преступление». («The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense».)
   
• «Студентов, ранее изучавших Бейсик, практически невозможно обучить хорошему программированию. Как потенциальные программисты они подверглись необратимой умственной деградации». («It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration».)

Дейкстра умер 6 августа 2002 года. Сегодня, спустя десять с небольшим лет после его смерти, мы вправе оглянуться вокруг и спросить себя: а насколько изменились обстоятельства? Иными словами: а сейчас (в наши дни) среди широко употребляемых языков программирования есть ли такие языки, использование которых влечёт для склонных к ним программистов почти неминуемый риск заметной профессиональной деформации?

Как мне кажется, они есть; и это прежде всего те языки, которые подпадают под определение write-only language, то есть поощряют написание такого исходного кода, прочтение и понимание которого слишком трудно, неоправданно трудно (как правило, даже труднее, чем его написание автором кода), хотя в нормальных языках должно быть наоборот.

Наиболее употребительным из таких языков является Perl.

Будьте покойны: я не намерен просто ткнуть пальцем в Perl и объявить, что он плох. Это вышло бы слишком малоубедительно без доказательств и подробностей. И именно поэтому прямо сейчас на примере, взятом из жизни, я покажу вам четыре механизма, при помощи которых Perl воздействует на сознание программиста и поощряет сочинение им такого кода, который оказывается неприглядным write-only.