Для чего Java-программисты прибегают к native методам? Иногда, чтобы воспользоваться сторонней DLL библиотекой. В других случаях, чтобы ускорить критичный алгоритм за счет оптимизированного кода на C или ассемблере. Например, для обработки потокового медиа, для сжатия, шифрования и т.п.

Но вызов native метода не бесплатен. Порой, накладные расходы на JNI оказываются даже больше, чем выигрыш в производительности. А всё потому, что они включают в себя:

1. создание stack frame;
2. перекладывание аргументов в соответствии с ABI;
3. оборачивание ссылок в JNI хендлы (jobject);
4. передачу дополнительных аргументов JNIEnv* и jclass;
5. захват и освобождение монитора, если метод synchronized;
6. «ленивую» линковку нативной функции;
7. трассировку входа и выхода из метода;
8. перевод потока из состояния in_Java в in_native и обратно;
9. проверку необходимости safepoint;
10. обработку возможных исключений.

Но зачастую native методы просты: они не бросают исключений, не создают новые объекты в хипе, не обходят стек, не работают с хендлами и не синхронизованы. Можно ли для них не делать лишних действий?

Да, и сегодня я расскажу о недокументированных возможностях HotSpot JVM для ускоренного вызова простых JNI методов. Хотя эта оптимизация появилась еще с первых версий Java 7, что удивительно, о ней еще никто нигде не писал.

Всем привет.

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

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

Перевод поста Эда Пегга Младшего (Ed Pegg Jr) "Martin Gardner’s 100th Birthday"

Я думаю, содержание этого поста будет интересно всем, кто любит математику и ее красоту, всем, кто знаком с замечательными книгами и задачами Мартина Гарднера, а также будет полезно учителям, школьникам и студентам. Все ссылки в данном посте ведут на сайты Wolfram Demonstrations Project (коллекция бесплатных интерактивных демонстраций, созданных пользователями системы Mathematica на языке Wolfram Language с помощью технологии Computable Document Format (CDF), при этом для вас доступны исходные коды всех демонстраций, а значит, вы можете каждую из них скачать, изучить и изменить под себя) и Wolfram MathWorld (крупнейшая и самая авторитетная онлайн-энциклопедия по математике).

^{Ачивка, которая даётся вам за то, что вы посмотрели свои ачивки (Galaxy Trucker)}

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

Посмотрите на эту ачивку, например:


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

В этой статье для начинающих android-разработчиков я постараюсь рассказать о том, что такое «утечки памяти» в android, почему о них стоит думать на современных устройствах, выделяющих по 192МБ на приложение, как быстро найти и устранить эти утечки в малознакомом приложении и на что нужно обращать особое внимание при разработке любого приложения.


Конечная цель этой статьи — ответ на простой вопрос:
Куда нажать, чтобы узнать, какую строчку в приложении поправить?

Ниже — вольный пересказ книги Running Lean, автор — Ash Maurya. Рейтинг Амазона — 4.8 из 5. Книга, насколько я знаю, на русский язык еще не переведена.

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

Допускаю, что нарушаю чьи-то права: пересказ лицензии не требует, но иллюстрации взяты из книги. Автору я писал в попытке прояснить этот вопрос, но ответа не получил.

Блог автора кгиги: practicetrumpstheory.com.

Структура пересказа

• Введение в процесс Running Lean
  • Три важнейших методологии
  • Roadmap
• Описание процесса Running Lean
  
  • Составьте «План А»
    
    • Определите кто клиенты
    • Создайте бизнес-модели
    • Ранжируйте бизнес-модели
  • Протестируйте и измените план
    
    • Подготовьтесь к проведению экспериментов
    • Категории рисков и четыре фазы тестирования плана
      
      • Фаза 1. Поймите проблему
      • Фаза 2. Найдите решение
      • Фаза 3. Валидируйте качественно
      • Фаза 4. Верифицируйте количественно
• Три стадии стартапа
  
  • Соотношение трех стадий стартапа и четырех фаз тестирования плана
  • Держите правильный фокус
  • Привлекайте финансирование вовремя
  • Масштабируйте правильно

Доброго времени суток %username%. Не давно наткнулся на хороший туториал по созданию клона игры Flappy Bird используя LibGDX и этот туториал мне понравился своей простотой и детализацией.

Я отдаю себе отчет, что тема создания клонов данной игрушки изъела себя, но возможно кому-то пригодится еще один хороший туториал.

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

Игрок больше любит получать, чем терять.

При GameDev надо учитывать эту прекрасную особенность психики. Проиллюстрирую тремя играми: замечательным Faster than Light (родившемся ещё на ПК), популярном изначально планшетном Out There и пришедшем из настольного мира Galaxy Trucker.

Ни в одной из этих игр нет возможности сохраниться.

Привет, Хабр!

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

Привет, Хабр!

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

И да, гифок там еще больше, чем в прошлый раз.

13 лет назад английский подросток Адам Батчер (Adam Butcher) пришёл домой с премьеры «Властелина колец» и твёрдо решил, что должен сделать игру, в которой реализует всё то, чего не хватает во всех остальных глупых играх. Там должны быть приключения и головоломки, настоящий сюжет и борьба со злом.

Парню было 14 лет, он как раз освоил популярную программу Multimedia Fusion — и в тот же день взялся за дело, нарисовал главного персонажа Тобиаса и объект № 1 — меч.

В начале апреля я уволился с работы. От переизбытка свободного времени я решил написать игру для iOS. Игра про бедного кубика, которого постоянно преследуют другие геометрические фигуры. Настоящая драма. Кубику нужно продержаться как можно дольше без столкновений. Прототип игры был написан примерно за 8 часов. Всего разработка игры заняла 3,5 месяца. Чем я занимался все это время можно узнать ниже.

Создание игры процесс захватывающий и познавательный. Особенно это заметно, когда ремейк «классики» делаешь сам, руководствуясь идеями оригинала и десятками часов, потраченных на прохождение кампании. У меня не было сколь-нибудь значимого опыта разработки для Android'a, поэтому создание работающего «как надо» приложения для планшета поначалу выглядело довольно туманно, но от этого не менее притягательно. При наличии времени и возможностей, можно стряхнуть пыль со старых игр, подмазать и подклеить, добавив поддержку «больших» разрешений и окажется, что они выглядят не хуже современных продуктов, выложенных на маркете, даже с палитрой RGB565 без альфа-канала. Я предполагал, что будут подводные камни и заботливо спрятанные грабли, которые лежат тихонько во время разработки, но больно лупят по голове, стоит запустить игру на реальном железе. Чего сильно не хватало, так это отладчика, а возникающие проблемы лишь укрепили желание достичь поставленной цели. Под катом будет рассказ о том, как это все заработало.

Моя трёхлетняя дочка София в последнее время частенько упоминает «ноль», например, в таком контексте:

— Соня, вот ты вроде сначала не послушалась, а затем послушалась, что же получается?..
— Ну… ноль!

Т.е. ощущение отрицательных чисел и нейтральности нуля уже имеет, о как. Скоро поинтересуется: почему же это на ноль делить нельзя?
И вот решил я простыми словами записать всё, что я ещё помню про деление на ноль и всё такое.

Disclaimer. Этот пост написан на основе доклада на SQADays’15. Вы можете также посмотреть видео выступления или полистать презентацию. Обращаю внимание, что доклад был начального уровня, то есть пост будет интересен в основном менеджерам и начинающим тестировщикам. А также на то, что автор — ненастоящий сварщик и местами делает довольно грубые округления.

Меня зовут Алёна, и я релиз-менеджер. Отдел компании i-Free, в котором я работаю, в основном занимается приложениями под iOS и Android. Ещё мы поддерживаем Tizen, Windows Phone, альтернативные сторы, но в данном посте речь пойдёт об Apple iOS Appstore и Google Play.
В обоих маркетах, помимо платных и бесплатных приложений, есть возможность проводить внутренние платежи — ин-аппы (In-App Purchases).

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

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

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

Рассказ снова немного сумбурный и всех, кто не любит Android, С++, Live Wallpaper, Minecraft, велосипеды, поток сознания, который слабо привязан к теме и всё около того, хочу сразу предупредить что их может огорчить содержание этого поста, поэтому продолжайте чтение на свой страх и риск.

Со времён игры «2048» не было новых таких же увлекательных головоломок. Теперь есть: «Игра о квадратах».

Примечание от переводчика: если вам позволяет знание английского языка, то я настоятельно рекомендую ознакомиться с оригиналом. Её автор — один из основателей студии Mode 7, которые выпустили Frozen Synapse. Статья очень большая по объёму текста, поэтому, если у вас не получится осилить её за 1 подход, я бы предложил отложить на потом, и продолжить в другой день.

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

Ниже будет перевод статьи.

Marlight — это светодиодная RGBW лампочка, управляемая по радиоканалу с частотой 2.4 ГГц. Она может управляться как с пульта, который непосредственно передает на частоте лампочки, так и с помощью роутера, который подключается в домашней Wi-Fi. С помощью роутера, который транслирует команды, поступающие к нему по сети в радиопакет для лампы, лампами можно управлять из мобильного приложения, компьютера или домашнего сервера.



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