DISCLAMER

Статья является шуточной, но с долей правды (программирование, же). Данная статья также содержит код, который может смертельно навредить вашему зрению. Читайте на ваш риск.

Вступление

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

3 года назад я поверил в будущее nodejs и начал кампанию по имплементации этого языка в самые “проблемные” сервисы нашего проекта. У нас все получалось — нагрузка падала, стабильность повышалась. Но все же были грабли, о которых захотелось рассказать.

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

В прошлом году мы рассказывали про разработку приложения Контур.Эльба под Android (причем неоднократно). Реализовав в нем все задуманное, мы принялись за разработку версии под iOS, которая недавно появилась в App Store. Пост про разработку с использованием Xamarin.Forms будет позже, а пока сосредоточимся на, казалось бы, банальном вопросе: выкладывание приложения в App Store и общение с модераторами.

Начнём с выводов, которые мы получили в процессе общения с модераторами Apple:

• следует внимательно перечитывать App Store Review Guidelines: рекомендации меняются, и то что вчера было разрешено, сегодня могут уже запретить;
• модераторы Apple не всегда внимательно изучают приложение и могут пропустить контент внутри;
• нужно внимательно читать ответы модераторов;
• решение после проверки может не соответствовать правилам App Store. Пример в тексте ниже: требование подключения in app purchase для приложения без поддержки платных фич;
• в непонятных ситуациях лучше сразу написать апелляцию, чтобы не тратить неделю на ожидание ответа. Если ответ не устраивает или непонятен – новые апелляции;
• модерация может занять много времени: минимум 8 дней, из которых 7 дней – ожидание в очереди на проверку.

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

Привет.

Вкратце. Не так давно на хабре была статья о скрещивании AdMob и Qt путём реализации кроссплатформенной библиотеки. Вот только не было там возможности интегрировать библиотеку с QML приложением. Недавно, решив встроить AdMob в своё небольшое новое Qt Quick приложение, я столкнулся с этой проблемой и реализовал небольшую обёртку. Но, так как я решил встроить рекламу, то мне понадобилась и аналитика.

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

Но вдруг я наткнулся на интересный cross-promoution сервис — StartAd.mobi. Его суть в том, что в первый месяц сеть бесплатно даёт тебе в разы больше трафика, чем приводишь ты. Стало интересно, внедрил и этот сервис в проект для того чтобы проверить статистику и попытать счастья.

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

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

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

Так родился AdCtl.

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

Вторая часть

От переводчика. Статью написал Итай Керен, основатель инди-студии Untame, автор игры Mushroom 11. Получился настоящий учебник по управлению камерой в играх с боковой прокруткой. Хоть там нет ни строчки кода ни на каком языке (вру, одна есть), думаю, несложно будет перевести всё это в инструкции для компьютера. Обязательно к прочтению всем программистам и дизайнерам, которые занимаются динамичными 2D-играми. Терминологию я переводил больше по смыслу: например, position-locking — «привязанная камера». Да, и для многих игр до 1983 года показана версия для Dendy — немного неисторично, но простим.

Введение

Работая над игрой Mushroom 11, я натолкнулся на множество дизайнерских и технических вопросов. Я не рассчитывал, что кто-то напишет о вершинной анимации или плавном изменении формы, но я удивился, что по работе с камерой, задаче с 30-летней историей, тоже практически не пишут.

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

“Это унылое диалоговое окно действительно нужно?”

В этой статье я изложил главные принципы Material Design и дал советы по их воплощению. Текст написан по следам мастер-класса для разработчиков, который мы, Роботы, устраивали совместно с российским офисом Google (Think Mobile).


Когда-то все продукты Google выглядели по-разному плохо. Даже один продукт на разных платформах выглядел неконсистентно.

Все стало меняться в 2011 году, когда в Google начали усиленно работать над унификацией визуальной части экосистемы своих продуктов и назвали все это Project Kennedy.

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

Речь, конечно же, пойдёт не о том, что можно в приложении поймать событие нажатой клавиши и просто задать уровень звука. Дело в том, что можно работать с приложением и на фоне слушать музыку, запущенную на плеере. Или просто один раз исправить файл системны — и оно всегда будет работать. Необходимо, чтобы при нажатии на клавиши регулировки уровня звука на устройстве, менялся системный уровень звука (ну там, выпрыгивал регулятор громкости и т.д.; ну, вы меня поняли).

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

Итак, приступим.

Как уважаемые хабровчане знают, вот уже почти год мы разрабатываем маленький компьютер (примерно с SD-карточку), работающий под OpenWRT, со встроенным Wi-Fi, USB, Ethernet, азартными играми и доступными женщинами. Дмитрий dzhe уже несколько раз писал про него — и, в общем, с каждым разом собирал в комментариях один и тот же вопрос: а зачем вы вообще его делаете? Ну ведь есть же Raspberry Pi, стоит он столько же, есть VoCore, Carambola, Edison, в конце концов, — зачем нужен ещё один «нанокомпьютер»?

Пожалуй, надо наконец на этот вопрос ответить — заодно отметив этим ответом появление у нас своего корпоративного блога (спасибо, Хабр!), а также запуск отдельного веб-сайта, посвященного только этому проекту.



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

Всем привет!

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

Итак, конструкция разработана, собрана на макетной плате, проверена в действии. Дальше — печатная плата. Если верить форумам, то многие (в том числе и мои знакомые) используют Sprint-Layout. Но ведь это ручная работа, тот же карандаш и бумажка, только в электронном виде. Зачем все эти ядра процессора и гигабайты памяти, если приходится всё равно работать ручками? Признаюсь, меня это всегда коробило.

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


Красивая картинка для привлечения внимания

Программный рендеринг (software rendering) — это процесс построения изображения без помощи GPU. Этот процесс может идти в одном из двух режимов: в реальном времени (вычисление большого числа кадров в секунду — необходимо для интерактивных приложений, например, игр) и в «оффлайн» режиме (при котором время, которое может быть потрачено на вычисление одного кадра, не ограничено настолько строго — вычисления могут длиться часы или даже дни). Я буду рассматривать только режим рендеринга в реальном времени.

У этого подхода существуют как недостатки так и достоинства. Очевидным недостатком является производительность — CPU не в состоянии конкурировать с современными видеокартами в этой области. К достоинствам стоит причислить независимость от видеокарты — именно поэтому он используется как замена аппаратного рендеринга в случаях, когда видеокарта не поддерживает ту или иную возможность (так называемый software fallback). Существуют и проекты, цель которых — полностью заменить аппаратный рендеринг программным, например, WARP, входящий в состав Direct3D 11.

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

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

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

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

В статье описан путь от идеи до создания домашнего портативного анализатора качества воздуха (CO2, влажность, температура, давление).

Вступление

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