Предисловие

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

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

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

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

В продолжении статьи о кроссплатформенной и кросс-аппаратной оптимизации, на примере задачи поиска полным проходом по таблице из 5 полей и 10 000 000 строк, и неизбежности этой задачи даже при индексном поиске, я покажу как ускорить такой поиск в 3.5-5.3 раза с использованием C++ независимо от аппаратной платформы.
В предыдущей статье нам удалось ускорить поиск в 1.3 раза: GitHub.com
Мы не будем банально описывать конструкции языка, а покажем преимущества C++ при решении одного из этапов реальной задачи.
Мы по-прежнему пишем кроссплатформенно под MSVC11(MSVS2012) и GCC 4.7.2, и используем в них C и частично реализованный стандарт C++11.
Для упрощения понимания мы все ещё пишем без индексного поиска, но это решение в дальнейшем будет использоваться при индексном поиске.

Разрабатывать интерфейс Android приложений — непростая задача. Приходится учитывать разнообразие разрешений и плотностей пикселей (DPI). Под катом практические советы о верстке макетов дизайна Android приложений в Layout, который совпадает с макетом на одном устройстве а на остальных растягивается без явных нарушений дизайна: выхода шрифтов за границы; огромных пустых мест и других артефактов.

UPD: Пост спорный, но много ценных советов в комментариях

В подмножестве экосистемы Java, относящейся в основном к JNI (без которого никуда не деться, если приходиться интегрироваться с каким-то legacy или просто редким и специфическим кодом, написанном на С или каком-то другом языке), есть такое понятие, как java.library.path. Вкратце, это в некотором роде аналог classpath, только не для Java классов и *.jar файлов, а для нативных библиотек — системное свойство, которое указывает JVM, где искать эти самые нативные библиотеки (.dll в винде или .so под юниксами).

Свойство это устанавливается один раз, перед запуском JVM, через глобальные system properties, или как ключ -Dname=value для JVM, и после этого оно становится read-only. Точнее, менять-то его можно, но никакого эффекта на работу программы это не окажет, т.к. после того как вы обновите это свойство, JVM не перечитает его и не будет использовать новое значение.

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

Вот некое простое значение:


И мы знаем, как к нему можно применить функцию:


Элементарно. Так что теперь усложним задание — пусть наше значение имеет контекст. Пока что вы можете думать о контексте просто как о ящике, куда можно положить значение:


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

data Maybe a = Nothing | Just a

Позже мы увидим разницу в поведении функции для Just a против Nothing. Но сначала поговорим о функторах!

Присылает нам заказчик (Газпром) свою версию договора.
Понимаем — нашу они не подпишут,
вносим реквизиты и отправляем обратно.
Пропадают на две недели… возвращают протокол разногласий к договору.

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

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

Герой этого поста, ноутбук Dell Latitude E6420 ATG сошел с конвейера довольно давно, прибыл ко мне без упаковки и, по всем признакам, владелец относился к нему без особого пиетета. Тем не менее, я взялся за обзор с большим интересом. Ведь это самый настоящий ноутбук путешественника – и по задумке, и по сути. По задумке – потому что электронная начинка находится в магниевом противоударном корпусе. А по сути – потому что принадлежит ноутбук Ивану Дементиевскому, известному фотографу, путешественнику и журналисту. Вместе с Иваном этот экземпляр Dell Latitude E6420 ATG совершил восхождение на Гималаи, и после завершения экспедиции у меня была возможность осмотреть ноутбук снаружи и внутри.

В рамках внутренней активности с кодовым названием e-Lectures мы продолжаем выкладывать небольшие видео от наших мобильных разработчиков.

В этой лекции Степан stepango Гончаров расскажет об инструментах и методиках, применяемых в компании e-Legion для автоматизированного тестирования Android-приложений.


Презентация

В комментариях делитесь своими впечатлениями о докладе и рассказывайте, как вы тестируете Android-приложения.

Вчера в сообществе Habrahabr стартовал международный конкурс Intel App Innovation Contest 2013, или, если быть точнее, его русскоязычная часть. С 24 июля по 20 ноября мы предлагаем вам пройти путь от создания идеи Windows 8 Desktop приложения до ее реализации. Призовой фонд немалый: $100 000 + дополнительные призы от российской команды Intel Developer Zone. Есть, за что побороться!

Моему сыну, как и многим мальчишкам, нравятся автомобили. Причём чем они больше и необычнее — тем больше нравятся. Когда мы идём по улице, а мимо проезжает эвакуатор или снегоуборочная машина, он неизменно дёргает меня за руку, указывает на заинтересовавший его объект и говорит: «Папа, б-р-р!». Говорит он так потому, что ему один год и вышеуказанные два слова составляют 40% его словарного запаса. Тем ни менее, в общем мысль понятна — обратить внимание на автомобиль. Давайте подумаем, каким образом ребёнок в возрасте 8-10 лет сказал бы своему сверстнику то же самое. Что-то вроде «Ух ты, смотри какая крутая тачка!», да? Мысль та же, но обратите внимание — уже шесть слов вместо двух. И, наконец, представьте, каким образом то же самое скажет человек лет в тридцать: «Эй, смотри, да это же Ferrari California 2008-го года выпуска с двигателем V8 мощностью в 454 лошадиных силы и 7-ми скоростной коробкой-автоматом! Она до сотни разгоняется за 3.9 секунды!». Да, здесь уже больше деталей, но, если вы не автомеханик или фанат Ferrari — они вам скорее всего не нужны и не важны. Основная же мысль — всё та же, что и в «Ух ты, смотри какая крутая тачка!» или «Папа, б-р-р!». Но выражена она уже в 30 слов.

Вы заметили, как абстракция «интересный автомобиль» обросла деталями и нюансами, стала занимать существенно больше места в тексте и времени на понимание, анализ и ответ? То же самое происходит и с программным кодом.

«Как автоматизировать сочинение музыки?» — этот вопрос тревожит умы музыкантов еще со времен средневековья. Кеплер превращал траектории движения планет в музыку; Моцарт и его современники изобрели игру в «музыкальные кости» — они броском кубиков выбирали из большой таблицы такты и составляли из них менуэты. Но только с появлением компьютеров алгоритмическая генерация музыки получила настоящее развитие. Теория вероятности, марковские цепи, искусственные нейронные сети — все это стало инструментами создания музыки.

Недавно на хабре была статья про альтернативные крестики-нолики. Для не менее популярной у детей игры «Морской бой» мы тоже придумали продвинутый вариант, который позволяет надеяться не только на удачу, но и на умственные способности. Крайне незначительное изменение открывает целый спектр возможностей для применения логики.

Введение

Данная статья является продолжением цикла статей: Использование паттерна синглтон [1], Синглтон и время жизни объекта [2], Обращение зависимостей и порождающие шаблоны проектирования [3], Реализация синглтона в многопоточном приложении [4]. Сейчас я хотел бы поговорить о многопоточности. Эта тема настолько объемна и многогранна, что охватить ее всю не представляется возможным. Здесь я заострю внимание на некоторых практичных вещах, которые позволят вообще не думать о многопоточности, ну или думать о ней в крайне минимальном объеме. Если говорить точнее, то думать о ней только на этапе проектирования, но не реализации. Т.е. будут рассмотрены вопросы о том, как сделать так, чтобы автоматически вызывались правильные конструкции без головной боли. Такой подход, в свою очередь, позволяет значительно уменьшить проблемы, вызванные состояниями гонок (race condition, см. Состояние гонки [5]) и взаимными блокировками (deadlock, см. Взаимная блокировка [6]). Этот факт уже сам по себе представляет немалую ценность. Также будет рассмотрен подход, который позволяет иметь доступ к объекту из нескольких потоков одновременно без использования каких-либо блокировок и атомарных операций!

Для тех, кто не любит много читать и хочет знать все ответы сразу — напишу в первых строках этой небольшой статьи, что, по моему скромному опыту, в «топ» App Store попасть ужасно трудно, и для этого требуется приложить недюжинные усилия. Более того, скажу вам, что крупные издатели вылезают в «топ» именно за счет налаженной работы с журналистами, блогерами и всевозможными порталами пишущими про мобильные приложения, ну и разумеется за счет четко налаженной системы маркетинга приложений, направленной на увеличение количества скачиваний. Чуть легче «запихнуть» в топ бесплатное приложение, это разумеется при условии, что Apple его заметит и поставит в «New & Noteworthy» (Новое и Заслуживающее внимания) в App Store. Ну а теперь обо всем по порядку.

В поисках утраченного ковчега – часть I

Представим, что вы тертый в боях игрок. Старый. Опытный. Человек, которого трудно удивить. Человек, который многое повидал. Человек, который видел Истоки. Каждая новая игра сопровождается вашим скрипом, — «А вот раньше…», «Помню, были времена…», «Детки, то, что вы считаете новым, не более чем хорошо забытое старое, я это видел в 19..». Предположим также, что вы новый Индиана Джонс своего времени, боец невидимого археологического фронта, который каждый божий день пытается отыскать свой Грааль. Грядущее вас интересует мало, настоящее вызывает скепсис, цель ваших поисков – прошлое. Полагаю, что нам с вами, сегодня, по пути.

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

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

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

Выставите любой палец левой руки вперед. Давайте, не стесняйтесь, никто не будет над вами смеяться. Это нужно для важного эксперимента. Выставили? Теперь представьте что вы — это ваш палец (ну и бред). Повернитесь под прямым углом направо, затем наверх, и наконец налево. Где вы оказались? Правильно, в том же месте, но уже на спине.

С некоторой натяжкой именно так работает вращение с помощью углов Эйлера. Немного непредсказуемо и неудобно, не правда ли? Углы Эйлера имеют несколько недостатков, но есть одно особенно нехорошее свойство из-за которого вы не захотите с ними связываться. Его имя — Gimbal lock.

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

Внимание! Заходя под кат вы подвергаетесь риску поломать голову.

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

Итак, с чего начать?



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

Немного подробнее остановимся на каждом пункте.

Сегодня я расскажу про то, как устроено взаимодействие с модемом в ОС Android. В данной статье описывается структура компонентов операционной системы Android, ответственных за сетевое взаимодействие по протоколам пакетной передачи данных – GPRS, EDGE, 3G и т.д.
Эта статья содержит большое количество теории, практика же будет во второй статье.

Описание слоя радиоинтерфейса

Рассмотрим, так называемый, слой радиоинтерфейса, от английского – Radio Interface Layer. В ОС Android представляет он представляет собой абстрактный слой между сервисом телефонии (android.telephony) и модемом.


Рисунок 1. Слой радиоинтерфейса.

Awesomium — это библиотека, для интеграции браузера на базе Chromium в своё приложение. Вся прелесть Awesomium состоит в том, что его можно интегрировать в приложение практически любого типа (есть примеры интеграции в 3D игры на базе Unity3D), он обладает широким набором возможностей для разработчика и, честно говоря, с ним просто приятно работать.

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

И вот накопив некоторые знания я решил ими поделится. Уверен, что я не первый и не последний, кто будет проходить этот путь.