Всем привет!

Недавно передо мной встала задача написания своих кастомных аннотации и их обработки во время компиляции. Первый вопрос, который я себе задала: с чего начать? После анализа я решила поделиться с вами ответом на этот вопрос.
Думаю, рассказывать, что такое аннотации в java и с чем их едят, не имеет смысла, так как каждому юному программисту это знакомо ( а кому не знакомо, может прочесть самостоятельно). К тому же на хабре есть интересная ознакомительная статья об этом явлении.
Но сегодня я хочу поговорить именно о кастомных аннотациях в Android-приложении, которые обрабатываются в процессе компиляции проекта вашим собственным обработчиком и о автогенерации классов на их основе. А так же, по ходу дела, расскажу вам, как быстро все настроить в IDEA (сама я пользуюсь версией 12.1, возможно в других есть отличия).

Требуемые знания: знакомство с методами линейной бинарной классификации (e.g. SVM (см. SVM Tutorial)), линейная алгебра, линейное программирование

Рассмотрим линейную задачу бинарной классификации (если задача линейно неразделима, её можно свести к таковой с помощью симметричного интегрального L-2 ядра(см. SVM)). При решении такой задачи классифицируемые элементы (далее образцы) представляются в виде элементов векторного пространства размерности n. На практике в таких задачах n может быть чрезвычайно большим, например для задачи классификации генов оно может исчисляться десятками тысяч. Большая размерность влечёт, по-мимо высокого времени вычисления, потенциально высокую погрешность численных рассчётов. Кроме того использование большой размерности может требовать больших финансовых затрат (на проведение опытов). Постановка вопроса такова: можно ли и как уменьшить n отбрасыванием незначимых компонент образцов так, чтобы образцы разделялись «не хуже» в новом пространстве (оставались линейно разделимы) или «не сильно хуже».

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

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

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

Некоторые сложности обнаруживаются в ленивых языках:

fib = 1:1:(zipWith (+) fib (tail fib))

Здесь fib присутствует и в левой и в правой части, то есть мы получаем полноценное уравнение, решением которого будет бесконечная последовательность чисел Фибоначчи. Так как на бесконечных последовательностях естественным образом определяется топология, Haskell может решить это уравнение методом проcтых итераций (через оператор неподвижной точки).

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

Но есть язык, в котором уравнения являются важнейшей частью — это Modelica.

model Point
 Real x,y;
equation
end Point;

model Line
 parameter Real len;
 Point p1,p2;
equation
 len = (p1.x-p2.x)^2 + (p1.y-p2.y)^2;
end Line;

Здесь отрезок определяется как координаты концов и длинна, при этом длина и координаты связаны очевидным уравнением.

(К сожалению, source такого языка не знает, а вставить раскрашенный pygment-ом html не получается.)

Я расскажу вам про маленький проект, позволяющий использовать 32 битные версии расширений в 64 битной версии Total Commander-а (далее TC). Проект находится на стадии demo и позволяет использовать WCX модули с минимальным, необходимым набором функции (просмотр и извлечение содержимого архивов или все что можно представить в виде архивов). Ну и в конце опрос о востребованности такого решения и доведения проекта до некого уровня, покрывающего всю возможную часть API и все возможные категории модулей.

Всем хабрапривет!
Как-то понадобилось мне в Qt 5.1.1 для WinXP в VS2009 реализовать многопоточное приложение с интенсивным обменом сигналами. Взял я Шлее, вычитал у него, что нужно унаследовать класс от QThread и — вуаля, велком в многопоточность! На всякий случай заглянул в документацию Qt — там никто не возражал против наследования от QThread своего класса. Ну что же — порядок, сделано! Запускаю — вроде как работает, но как-то не так… Начинаю в режиме отладки отслеживать — а там творится черт знает что! То сигналы не выходят, то выходят, но как-то криво и из другого потока. Одним словом, полный бардак! Пришлось основательно по-google-ить и разобраться в теме (мне помогли статьи тут, здесь и там). В итоге я сделал шаблон класса на С++ (вернее, целую иерархию оных), что мне позволило в итоге писать (относительно) небольшой код класса, живущего в другом потоке, который работает правильно и стабильно.
Upd: в комментариях мне подсказали более качественный подход — я его описал в новой статье.

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

Я уверен вы, еще не слышали слово «Volley», это библиотека, представленная на Google I/O 2013 Ficus Kirkpatrick.

Для чего библиотека Volley?

Volley это библиотека, которая делает сетевые приложения для Android проще и, самое главное, быстрее.

Она управляет обработкой и кэшированием сетевых запросов, и это экономит драгоценное время разработчиков от написания одного и того же кода сетевого запроса/считывания из кэша снова и снова. И еще одно преимущество, меньше кода, меньше количество ошибок :)

Обычно мы пишем один и тот же код сетевого запроса в AsyncTask, логику обработки ответа от Web API и отображения его в View. Мы должны заботиться об отображении ProgressBar/ProgressDialog внутри OnsourceExecute() и OnPostExecute(). Я знаю, что это не трудная задача, но все же рутинная. Иногда бывает скучно, даже когда определен базовый класс для управления ProgressBar/ProgressDialog и многими другими вещами. Так что теперь можно сказать, Volley может быть мощной альтернативой AsyncTask.

Добрый день, жители Хабра!
Сегодня мы будем писать фреймворк с названием Mechanic Framework для удобной разработки игр под андроид.

Что нам потребуется:

• Установленные Eclipse и Android SDK
• Приличное знание Java либо другого С-подобного языка. Лучший пример – C#
• Терпение

Время, проведенное за компьютером, сводится в основном к «смотрению в экран»: пишет ли человек код, смотрит фильм, играет или узнает новости. Просто потому, что основное чувство человека — зрение. И оно во многом определяет восприятие реальности, механизмы взаимодействия с ней, и направляет развитие многих технологий.
Обычный пример эволюции железа и софта за последние несколько десятилетий: сравните Wolfenstein 3D (1992) и Crysis 3 (2013). Как продвинулась и усложнилась компьютерная графика за это время сложно недооценить.
Но увы, этого нельзя сказать о звуке. О том, как исправить ситуацию, и будет статья.

Изображение со страницы peripheriques.free.fr/blog/index.php?/past/2010-pure-data-read-as-pure-data

Если вы фрилансер или любите экспериментировать с экзотическими средами под С++, то стоит обратить внимание на экосистему Ultimate++, о которой я узнал совсем недавно благодаря циклу статей Семена Есилевского (ч.1, ч.2, ч.3, ч.4 — все есть на вики) с таким финальным напутствием:

«Перевешивают ли выгоды U++ его необычность и высокий «барьер вхождения»? На мой взгляд, да. U++ – прекрасный выбор для кроссплатформенных проектов, которые разрабатываются «с нуля», особенно если предполагается интенсивное использование баз данных.»

Под катом те нюансы U++, которые удалось раскопать на форуме и в мануалах за месяц ежедневной работы над редактируемым справочником документов, хранящихся в базе. Сразу отмечу, что сравнения с «замечательной троицей» не будет, так как раньше для простейшего gui использовал WTL и с надеждой смотрел на библиотеку eGUI++, которую, к сожалению, автор забросил, а подхватить некому.

Добрый день, Хабрахабр!
Решил написать этот топик на тему скриптов

Что нужно знать?

• С++ на приличном уровне (в уроке будут шаблоны — template)
• Lua, очень легкий скриптовый язык. Советую этот урок.

Почему писать диалоги игры в .cpp файле было большой ошибкой

Если вы разрабатывали большие проекты (к примеру, масштабные игры), замечали, что с каждой новой сотней строк кода компиляция идет медленней?
В игре создается больше оружия, больше диалогов, больше меню, больше etc.
Одна из самых главных проблем, возникающих в связи с нововведениями — поддерживать бессчетное множество оружия и бейджиков довольно сложное занятие.
В ситуации, когда просьба друга/босса/напарника изменить диалог или добавить новый вид оружия занимает слишком много времени, приходится прибегать к каким-то мерам — например, записи всей этой фигни в отдельные текстовые файлы.
Почти каждый геймдевелопер когда-нибудь делал карту уровней или диалоги в отдельном текстовом файле и потом их считывал. Взять хотя бы простейший вариант — олимпиадные задачи по информатике с файлом ввода

Но есть способ, на голову выше — использование скриптов.

Только ленивый не знает сегодня о том, что такое голосовой помощник Siri. Когда два года назад этот продукт был показан на презентации нового iPhone 4S, многие посмотрели на развитие IT-индустрии по-новому. Действительно, искусственный интеллект в кармане, понимающий естественную речь, еще не показывал никто.

Многие в то время начали говорить о том, что Apple может уже на следующем WWDC предоставить всем программистам под iOS возможность использовать открытое API ассистента Siri для своих собственных программ. Картина вырисовывалась радужной — любое приложение смогло бы реагировать на пользовательские фразы, исполняя различные команды. Действительно, если в магазине AppStore так много разных полезных приложений, почему бы им не дать возможность управления голосом? Тем более что такой вид коммуникации с пользователем, как речь, быстро стал трендовым после выхода iPhone 4s.

О том, удалось ли это сделать Apple, и что удалось сделать нам, читайте далее.

Предисловие

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

В далеком (а может и не очень далеком) 1975 году Альфред Ахо и Маргарет Корасик опубликовали статью, в которой был подробно описан алгоритм эффективного поиска всех вхождений всех строк-образцов в заданную строку. В дальнейшем этот алгоритм и получил название «алгоритм Ахо-Корасик». Неудивительно, что через некоторое время появились технические и «художественные» переводы данной статьи на русский язык. Порой мне даже встречались вольные изложения сути алгоритма в том виде, в котором его понимает автор. Причем последний, судя по тексту, узнал об алгоритме далеко не из первоисточника. Я не знаю существовал ли перевод, который послужил первоисточником проблемы, но мне всё больше и больше попадаются статьи с описанием алгоритма Ахо-Корасик, в котором допущена одна и та же кардинальная ошибка. Последней каплей была статья пользователя rmq на хабре, которую данная ошибка не миновала. Собственно об этой ошибке мне и хотелось бы рассказать общественности в своей статье.
Замечание: статья пользователя rmq, как выяснилось позже, не содержит этой ошибки. Как она решена там расскажу ниже. А ему огромное спасибо, если бы не его топик я бы не написал свой и не получил бы инвайт!
Перед началом, еще пара слов о целевой аудитории: Скорее всего, тем, кто давно знаком с алгоритмом Ахо-Корасик, моя статья будет не интересна, так как о его особенностях они давно уже знают. По крайней мере, все мои знакомые программисты не один раз применявшие данный алгоритм знают о существовании его неверных интерпретаций не понаслышке. А вот новичкам и тем, кому не довелось часто применять его на практике, эта статья может оказаться довольно полезной.
Итак, начнем.

Доброго времени суток, Хабрахабр. Сегодня на крыле принес еще один перевод я (pdf-ки гугловского стайл гайда выложены). Хотя, кто знает, если кто-то оценит сию работу — быть может появится и продолжение. Как-то днём одним, предложил мне мой широко известный в узких кругах коллега scraplesh почитать ресурс — The Hitchhiker’s Guide to Python! называемый. Ресурс этот понравился мне. Понравились советы выдаваемые там. Понравилась канва повествования и вообще понравилось направление мысли автора. А если что-то хорошо на Ваш вкус, то нужно передавать это из уст в уста:) Итак, решил я сделать перевод данного ресурса. Но не всё так сразу — сначала будет пробная статья «на отклик» хабрасообщества. Если уважаемым гикам понравится сия тематика и изложение — будем стараться выпускать новые части. На первый «отклик» я выбрал раздел — "Writing Great Code" и в нем два подпункта «Structure is Key» и «Modules». Откликнемся под катом.

Эта небольшая заметка о том, как с приходом нового стандарта C++11 изменились требования стандартных контейнеров к своим элементам. В C++98 от элемента контейнера требовалось, по сути, наличие «разумных» конструктора копирования и оператора присваивания. Если, например, объект вашего класса владеет каким-либо ресурсом, копирование обычно становится невозможным (по крайней мере, без «глубокого» копирования ресурса). В качестве примера давайте рассмотрим следующий класс-обертку вокруг FILE*, написанную на C++98:

class File
{
    FILE* handle;
public:
    File(const char* filename) {
        if ( !(handle = fopen(filename, "r")) )
            throw std::runtime_error("blah blah blah");
    }
    ~File() { if (handle) fclose(handle); }
    // ...
private:
    File(const File&); //запретить копирование
    void operator=(const File&); //запретить присваивание
};

Даже если код тривиален, вы всё равно должны его тестировать.
Пару дней назад, Роберт Мартин опубликовал пост «Прагматичность TDD», (здесь лежит перевод — прим.переводчика) где он рассказал о том, что не тестируют абсолютно весь код. Среди исключительных ситуаций, когда не стоит применять TDD, дядя Боб упоминает написание GUI-кода, и я вижу смысл в таких утверждениях, но среди исключений есть парочка, на мой взгляд, нелогичных.

Начало Код с душком (рефакторинг М. Фаулера) .
В продолжении, техника рефакторинга по книге Рефакторинг. Улучшение существующего кода Мартин Фаулер.

Синтаксис будет на C#, но главное понимать идею, а её можно использовать в любом другом языке программирования.

Вторая часть: Оптимизируем Boid'ов на Unity

Задумывались ли вы когда-нибудь о то, почему птицы летая большими стаями никогда не сталкиваются и не коллапсируют в огромный галдящий перьевой ком? Хм, если подумать, это было бы круто. В любом случае, однажды в 1986 нашёлся человек по имени Крейг Рейнольдс, который решил создать простую модель поведения птиц в стаях и назвал её Boids. В модели у каждого боида есть три базовых правила: Separation, Alignment и Cohesion. Первое заключается в избегании столкновения с соседями, второе заставляет лететь примерно в ту же сторону что и соседи, а третье говорит не летать в одиночку и держаться группы. Эти простые правила позволяют создать правдоподобные стаи птиц, рыб и другой живности, чем и пользуются в кино и игровой индустрии.

В статье я расскажу как можно реализовать эту модель на практике. Для разработки я использую Unity и C#, но большинство вещей верны для других движков и языков. В этом туториале я не разжёвываю основы работы с Unity, подразумевается, что вы знаете эффект комбинации Ctrl+Shift+N на сцене, умеете работать с инспектором, дублировать и двигать объекты. Если нет, то советую начать с этой статьи. Или можете просто посмотреть на картинки.