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


Уязвимость рекурсивных алгоритмов навигации муравья: спираль смерти

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

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

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

Когда (уже достаточно давно) в одном из своих проектов я столкнулся с необходимостью выбора в настройках одного из трех параметров, решение было очевидно — RadioButton. Но по ряду причин, типа экономии места на экране и некоторых других, возникло желание использовать нечто вроде ToggleButton. Поскольку стандартный Toggle имеет лишь два состояния, был использован костыль в виде программной обработки некоей циклично меняющейся переменной, в зависимости от которой менялись свойства стандартного элемента вроде обычной Button или ImageButton – уже даже не помню. Способ вполне работоспособный, однако не без греха. Первый и самый главный – нарушается Генеральная линия партии, призывающая к раздельному хранению ресурсов и программного кода. Ну и при большом количестве подобных элементов управления код теряет всю свою изящность и привлекательность. Инкапсуляция, опять же, жутко страдает. Посему было решено создать кастомный элемент.

Поисковая оптимизация для AppStore и Google Play — это комплекс мер по улучшению видимости мобильных приложений в поисковой выдаче AppStore и Google Play Market. Сокращенно называется ASO — Appstore Search Optimization.

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

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

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

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

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

Доброго времени суток.

Мы с товарищем занимаемся разработкой под Android уже несколько лет. Создавали игрушки на чистом Android, OpenGL, а также Unity3d. Главной проблемой первых двух технологий является непереносимость на разные мобильные платформы. Собственно, именно поэтому мы стали использовать Unity3d.

Это довольно интересная штука. Она сочетает в себе огромные возможности программирования при помощи мышки, а также программирования на скриптовом языке, смахивающем на C#. Так как мы Java разработчики, то хотелось написать что-то кроссплатформенное на Java. Выбор пал на LibGDX. Открыв мануал и скачав пару специальных сборщиков скелета проекта на LibGDX, начали работать.

В результате большую часть времени мы потратили не на программирование, но на настройку проекта, настройку gradle, а также добавление Google Play Services. В результате, набив шишки, решили написать эту статью.

Приветствую!
С приходом material дизайна приходят и новые элементы. Например, появился RecyclerView, который многим уже известен. Про него на хабре писали не раз: тыц, туц.

Вроде как пользоваться им — понятно, но ведь хочется большего. Обычно при переходе на новые альтернативы чего-то не хватает. Вот и мне не хватило того, что есть. Понадобилось мне сделать parallax эффект, как в Google Play на странице конкретного приложения. Реализации для ListView и ScrollView имеются. Поискал я в великом и могучем, и все, что нашел — этот репозиторий. Решение вроде рабочее, да и народ пользуется. Однако мне не понравилось его юзабилити. И как водится, решил написать свое.

Книги, которые должен прочитать Java программист: от новичка до профессионала

[Примечание переводчика: термины градации «профессионализма» оставлены англоязычные в связи с трудностью их адекватного перевода на русский и несовпадением с привычными Junior-Middle-Senior-Lead. Перевод достаточно вольный — если знаний языка хватает, то лучше читать оригинал, как и советует автор. Оба языка для меня не родные, так что про ошибки сообщайте в личку — исправим. Здесь и далее в квадратных скобках примечания переводчика]

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

Напоминаю, есть мужик Дэвид Сирлин, который известен чемпионством по Street Fighter и в GameDev. Он написал книгу про то, как побеждать и готовиться к турнирам. Первая вступительная часть тут. Ниже — выжимка части II и мои комментарии.

Вот мы и дошли до настоящего мяса. Это разборы игровых ситуаций и конкретные примеры того, как думает оппонент. Например:

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

Как показывает мой скромный опыт, родные MediaPlayer, MediaMetadataRetriever, а так же другие классы, которые так или иначе основываются на них (VideoView, ThumbnailUtils, к примеру), являются крайне ненадежными в использовании. Возможно, проблема в том, что они реализованы нативно, и меняются от версии к версии, но факт остается фактом — их поведение на разных устройствах предсказать невозможно, причем это даже не зависит от мощности железа.

Спешу поделиться с коллегами накопленным опытом при разработке для Android Wear.

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

В своей книге Designing Mobile Interfaces (2011) дизайнер Стивен Хубер ввел понятие The Thumb Zone («зона большого пальца») — область экрана, наиболее удобная при использовании телефона одной рукой. С года издания книги средний размер смартфона заметно увеличился, и «мертвая зона» — область, которую сложно достать пальцем одной руки, — также стала больше.

Изображение. «Зона большого пальца» для 5–4,7-дюймового экрана, если держать телефон в левой и в правой руке, соответственно. Изображение основано на публикации Скотта Хэрффа.

Доброго времени суток.

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

Поразмыслив, я вспомнил интересную статью о настройке сервера ip-телефонии Asterisk на маршрутизаторе Mikrotik. Так как у меня дома установлен роутер именно этого проиводителя, не раздумывая, я решил поднять на нём веб-сервер nginx.

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

Допустим мы пишем библиотеку, она использует другие библиотеки и, в частности, для примера, support library. Если бы мы использовали maven, то в pom файле просто прописали зависимости и не парились. Но что если нашу библиотеку будут использовать люди, которые не пользуются системами сборок или пользуются ant' ом?

Мы можем положить зависимости рядом с нашим jar. Но тогда неизбежны конфликты библиотек разных версий, например, если мы используем одну версию support library, а в самом приложении другая. Тогда придется руками одну из них удалять.

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

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

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

Вступление

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

• JUL — java.util.logging
• log4j
• JCL — jakarta commons logging
• Logback
• SLF4J — simple logging facade for java

В данной статье будет рассмотрен каждый из указанных выше фреймворков на уровне «hello world». Будут приведены простые примеры использования основного функционала и конфигурирования. Статья не преследует цель сравнения логгеров между собой и выявление лучшего из них, эту возможность автор оставляет за вами, уважаемые читатели. В конце статьи будут приведены источники, где можно получить более детальную информацию по каждому фреймворку. Также перед прочтением данной статьи рекомендую ознакомиться с публикацией «Java Logging: история кошмара», где описана история развития систем логгирования в Java.

Идеей написать игру я загорелся еще в 2011 году. В августе 2011 года, не имея опыта разработки на PHP, обложившись книгами и этими вашими интернетами, по ночам писал небольшую браузерную космическую стратегию в реальном времени. Этакий клон OGame. Разумеется, со своими дамами и преферансом. Но проекту этому не суждено было родиться, в декабре 2011-го Родина-мать вдруг попросила отдать долг.

Вернувшись в декабре 2012 года, первым делом устроился в местную крупную IT-компанию. Нужно было максимально быстро вновь войти в рабочий ритм. К весне я уже не мог спокойно спать — мечтал писать игры. Второй попыткой было написать простенькую TD на Unity. Что-то даже получилось — пушки стреляли, мобы двигались. Но постоянно мучил страх, что не смогу довести дело до конца. Так оно и получилось. Семья, работа — свободного времени не было совсем. И только осенью 2014 года твердо решил — я сделаю игру и точка. Не буду спать, не буду есть, но сделаю. Этакий вызов на «слабо». Что из этого получилось читайте дальше.

В Java для введения порядка среди определённых объектов можно написать компаратор — класс, содержащий функцию compare, которая сравнивает два объекта. Альтернативой компаратору является естественный порядок объектов: объект реализует интерфейс Comparable, который содержит метод compareTo, позволяющий сравнить этот объект с другим. Сравнивающая функция должна вернуть 0, если объекты равны, отрицательное число (обычно -1), если первый объект меньше второго, и положительное число (обычно 1), если первый больше. Обычно реализация такой функции не представляет сложностей, но имеется один случай, о котором многие забывают.

Сравнение используется различными алгоритмами от сортировки и двоичного поиска до поддержания порядка в сортированных коллекциях вроде TreeMap. Эти алгоритмы завязаны на три важных свойства сравнивающей функции: рефлексивность (сравнение элемента с самим собой всегда даёт 0), антисимметричность (сравнение A с B и B с A должны дать разный знак) и транзитивность (если сравнение A с B и B с C выдаёт одинаковый знак, то и сравнение A с C должно выдать такой же). Если сравнивающая функция не удовлетворяет этим свойствам, алгоритм может выдать совершенно непредсказуемый результат. Причём скорее всего вы не получите никакого исключения, просто результат будет неверный.

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

Все началось год назад, когда моя первая игра (я работаю как инди в свободное время) была вполне благосклонно воспринята аудиторией Desura. «Нужно двигаться дальше», — подумал я и стал готовить игру на мобильные платформы. Сказано — сделано: 25 долларов на счет Google Play, форумы Unity в помощь, и вперед!

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

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

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

И еще один спойлер — под катом анализ конверсии до и после привлечения аудитории торрентофилов…