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

И действительно, как же доказать, что 2 × 2 = 4? Ответ под хабракатом.

Дисклеймер

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

Перевод статьи Introduction to CocosBuilder.
Автор оригинальной статьи Али Хафиджи, разработчик под iOS и Android.

CocosBuilder – это бесплатный инструмент, который позволяет быстро и легко управлять спрайтами, макетами и сценами при разработке вашей игры, использующей Cocos2D.

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

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

На случай, если вы пропустили предыдущие части — вот ссылки:
1 — Миникомпьютер из роутера с OpenWRT: разрабатываем USB-видеокарту
2 — Миникомпьютер из роутера с OpenWRT: пишем USB class-driver под Linux
Итак, приступаем к работе.

Добрый день, уважаемые хабровчане. В этом цикле статей мы с вами пройдем достаточно длинный, но весьма интересный путь по превращению обычного роутера в мини-компьютер с LCD-дисплеем. Для этого мы разработаем сначала USB-видеокарту на базе микроконтроллера STM32F103, потом тестовый драйвер, который позволит нам выводить на него графику, и, наконец – полноценный драйвер фреймбуффера, благодаря которому можно будет запустить настоящие графические приложения, такие как x-сервер. Заодно мы научимся включать наш код в дерево исходников OpenWRT, допиливать его ядро и делать прочие полезные вещи.
Ну а в самом конце мы получим результат, который, я надеюсь, вызовет ностальгическую слезу у многих читателей. Я постараюсь излагать материал таким образом, чтобы в конце каждого этапа мы получали осязаемый результат, не дающий угаснуть энтузиазму. Итак, начнем.

Доброго времени суток! В этом посте я хочу показать, как управлять электроникой через Интернет используя Raspberry Pi. Выглядеть это будет примерно вот так.



Краткое описание:

• Серверная программа, которая работает на Raspberry Pi, для того чтобы читать переменные
• Базы данных MySQL для хранения переменных
• Веб-страница Apache2, для того чтобы контролировать переменные

С недавнего времени у меня появилась настойчивая мысль, что профессиональное развитие сильно замедлилось и это хочется как-то исправить. Да, читаю книги, слушаю курсы, но в то же время приходит и понимание того, что возможно пришло время сменить работу, здесь вроде как все изучено, плавно уходим в рутину. Данная мысль сподвигла меня на рассылку своего резюме в несколько компаний — лидеров рынка. После прохождения собеседования в 3 из них, я решил, как водится внести свои 5 копеек в освещение обширной темы собеседования, а именно технических вопросов по Java коллекциям, с которыми приходится сталкиваться. Да, знаю, читатель скажет: «коллекции — избитая тема, сколько можно», но часть из приведенных ниже вопросов, я задавал своим знакомым разработчикам, которые занимают именно позиции разработчиков («крепких середнячков», по меркам недалекой от Москвы глубинки, которые уверенно справляются со своей работой на практике, а вот в теории скажем так есть пробелы, потому, что работа не требует решения каких-то нетривиальных задач, да и потому что не всем это интересно — изучать как внутри работает структура данных), вызывало растерянность. Думаю, что рассмотренный материал будет не очень интересен разработчикам выше уровня Junior (я попрошу их комментировать, дополнять и критиковать изложенный здесь материал), а вот Junior`ы уверен, найдут в этой статье интересное для себя.

Лечу Crash'и NSLog'ами. Недорого. Многолетний опыт. 100% гарантия.

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

Все началось с того, что на одном из относительно больших проектов начало стабильно вываливаться исключение при авторизации пользователя. «Ну и что тут такого? У всех бывает. Проверку на nil забыли поставить или где-то накосячили. „Тоже, мне, большое событие — crash на проекте“, — подумает большая часть программистов. В принципе — абсолютно согласен. Crash — не такое уж и редкое явление в программировании под iPhone, и с ним сталкиваешься по десять раз на день. Но этот был особенным. От него уже начало попахивать „магией“, когда мне сказали про его некоторые параметры и особенности:

• Воспроизводимость на симуляторе: 100%
• Воспроизводимость на устройстве: 0%
• Путь к крэшу (после локализации крэша): ~ 40 секунд
• Настройки оптимизации при компиляции (-O1,-O2...) не влияют на воспроизводимость
• XIB'ы в проекте не используются

Да выглядел он довольно безобидно:

// Code
UITextView * textView = [ [UITextView alloc] initWithFrame:CGRectMake(0, 150, _width, _height)];

// Exception
*** Terminating app due to uncaught exception 'CALayerInvalidGeometry', 
    reason: 'CALayer bounds contains NaN: [0 0; nan 200]'

»Ну тут же и ежу понятно, что width — после вычисления — NaN!", — подумал я. Бегло поглядев где и как вычисляется ширина вьюхи, и не найдя ничего особого опасного, я, для утверждения своей догадки, поставил перед созданием вьюхи NSLog. А вдобавок, и точку останова на строке с созданием элемента.

// Source:
NSLog(@"width = %f", _width);

//Output:
width = 200

«Гм», — подумал про себя я, и продолжил выполнение программы после точки останова. И крэша не произошло…

Clojure является диалектом Lisp, поэтому совершенно не удивительно, что работе со списками отводится ключевое место в языке. Правда, в отличии от традиционных диалектов (CL или Scheme), вместо классических двухслотовых списков в Clojure используется абстракция Sequence — «логический список». Фактически, это интерфейс, предоставляющий методы для работы с неизменяемыми, ленивыми и, возможно, бесконечными последовательностями. Данная статья описывает внутреннее устройство этих сущностей.

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




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

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

Для начала – что такое европейские языки. Предлагаю ограничиться государственными языками стран Европы. Так как границы Европы – вещь спорная, то отдельно оговоримся про соседние страны. Духовно близкий Израиль, а также Грузию и Армению можно отличить по письменности из той же блок-схемы, Азербайджан и Казахстан я включу по доброте душевной, а Абхазию и Южную Осетию – в качестве прогиба перед российской властью. Так что абхазский в наш классификатор попадёт, а баскский и гэльский – ну уж нет, перебьются.

Языков больше, чем типов письменности. Поэтому диаграмка получилась большая. Отличать языки друг от друга будем в основном по особенным буквам, в частности, по буквам с диакритическими значками (диакритикой). Диакритика бывает над гласной (в букве й), над согласной (буква č) или может как-то сопровождать букву (как в букве ç; строго говоря это не дикритика вовсе, но мы здесь будем придерживаться такого жаргона). Наиболее известные (с моей точки зрения) значки в Европе — это умляут (он же диаерезис: ü), гачек (č) и акут (é).

Тема изучения иностранных языков уже много раз обсуждалась здесь. В архивах можно найти много различных интересных способов и практических советов по поводу изучения языков. В какой-то момент я решил, что мне тоже, наверное, стоит поделится опытом, накопленным в процессе изучения иностранных языков: более-менее бегло я могу говорить на шести языках.
Всё, о чём я пишу здесь — это моё личное понимание проблемы изучения языков и моё видение возможных решений. Я не претендую на какую-либо истину или научность и не имею законченного профессионального образования в области лингвистики.
Я не буду рассматривать здесь изучение языка на уровне туриста, где достаточным уровнем является способность понять основные пункты меню в ресторане, сделать заказ или суметь спросить дорогу и понять, что тебе ответили. Знание языка на таком уровне, конечно, полезно, но это нельзя назвать «владением языком». Для меня уровень владения начинается с того момента, когда я могу спокойно читать тексты на этом языке используя лишь словарик, встроенный в электронную читалку (раньше AlReader, потом СoolReader, сейчас наконец PocketBook Reader).

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

В какой-то момент мне захотелось «научить компьютер» решать японские кроссворды так, как решаю их я сам. Никакой высокой цели, just for fun. Потом уже были добавлены способы, которые сам я применять не могу в силу ограниченных возможностей человеческого мозга, но, справедливости ради, со всеми кроссвордами из журналов программа справляется и без них.

Итак, задача простая: решить кроссворд, а если решений много, то найти их все. Решение написано на Haskell'е, и, хотя код достаточно существенно дополняет словесное описание, даже без знания языка общую суть понять можно. Если хочется пощупать результат вживую, на странице пректа можно скачать исходники (бинарных сборок не выкладывал). Решения экспортируются в Binary PBM, из него же можно извлекать условия.



Несмотря на то, что я пытался писать максимально понятно, это не в полной мере мне удалось. Под катом очень много букв и кода и почти нет картинок.

Приветствую достопочтеннейших Хабралюдей!


Не так давно, во время поиска новой работы, я получил очень интересное тестовое задание от ZeptoLab: написать за пару рабочих дней арканоид под iOS без использования сторонних библиотек типа Cocos2d/Box2d и т.п., то есть, на «чистом» OpenGL, что показалось мне весьма интересным. Кстати, об этом задании на Хабре уже писали, и даже устраивали разбор полётов. Итак, я бросил вызов судьбе и взялся за геймдев впервые после школьных упражнений с васиком в графическом режиме!

Уточню, что некоторые знания OpenGL у меня уже были, но весьма и весьма поверхностные. Можно сказать, что их не было ну почти совсем, я просто знал, что такое вьюпорт и что бывают какие-то там спрайты, что существуют матрицы преобразования… Так что данная статья могла бы быть озаглавлена "Как написать простую игру под iOS на чистом OpenGL, не зная его", но это слишком уж длинно.

В общем, если Вам интересно, как я это сделал за ~10 часов разработки и ~2 часа чтения, прошу под кат. (осторожно! много кода! мало картинок! ссылка на гитхаб и расслабляющее видео в конце!)

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

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

Приветствую всех!

Я поделюсь с вами опытом создания простейшей 2D игры с помощью Gideros Studio (прим. Далее GS),
среды разработки мультиплатформенных мультимедиа приложений для iOS и Android.

Особенности:
— Низкий порог вхождения
— Язык разработки LUA
— Хорошая справка
— Поддержка ARMv6+
— Отличная скорость (выше чем у Corona SDK)
— Фокусирование на разработке игровой логики
— Логика скриптинга схожа ActionScript (прим. Заманивают Flash разработчиков)
— OpenGL, OpenAL, Box2D

Условия лицензирования (прим. Годовые подписки):
— Community: free версия, отличается 2 секундным splashscreen при старте вашего приложения
— Indie: никакого splashscreen
— Professional: необходимо приобрести, если годовой доход выше $100,000

В её состав входит 4 инструмента:
— Studio: IDE для разработки
— Player: набор приложений для запуска и отладки
— TexturePacker: упаковшик спрайтов и текстур в атласы (прим. необходим для оптимизации)
— FontCreator: создание растровых шрифтов для вашего приложения из *.ttf,*.otf,*.ttc

Все утилиты так же мультиплатформенны и запустятся на следующих ОС:
— Windows
— OSX (64bit)
— Linux (Wine)

Для создания полноценного проекта для Android потребуется:
— Любая ОС
— Eclipse
— Android SDK (2.1+)
— JDK

Для iOS:
— OSX (64bit)
— Xcode

Все действия в данном цикле статей будут происходить в Windows, отладка будет происходить, как на локальной машине, так и на устройстве Android. И так, начнем!

В данной статье хочу привести небольшой пример работы с кастомизацией ExpandableListView — двухуровневого списка.

То, что должно получиться в итоге

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

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

Ниже показан результат обработки реального размытого изображения (не с синтетическим размытием). Исходное изображение было получено камерой Canon 500D с объективом EF 85mm/1.8. Фокусировка была выставлена вручную, чтобы получить размытие. Как видно, текст совершенно не читается, лишь угадывается диалоговое окно Windows 7.



И вот результат обработки:



Практически весь текст читается достаточно хорошо, хотя и появились некоторые характерные искажения.

Под катом подробное описание проблем деконволюции, способов их решения, а также множество примеров и сравнений. Осторожно, много картинок!

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

Итак, вуаля!


За источник информации была взята статья из вики. В блок-схеме «UTF-16 → CP 866» означает, что исходная кодировка была «UTF-16», а распозналась она как «CP 866».

Как всегда — кликабельно. Исходник в .docx: здесь.

Ранее в Android использовался C2DM (Cloud to Device Messaging), как сервис доставки Push-уведомлений на устройство. Но 26 июня он был официально отменен гуглом. На его место пришел новый GCM (Google Cloud Messaging).