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

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

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

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

EditorConfig это конфигурационный файл и набор расширений, к большому количеству редакторов кода и IDE (Далее просто IDE).

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

Файлы .editorconfig можно найти в таких проектах, как jQuery, Ruby, WordPress, и многих других.

Плагины доступны для большого количество IDE




Давайте разберемся, как это работает.

Практика code review или, если перевести на русский язык, инспекций кода появилась давно и уже успешно встроена в процессы разработки во многих компаниях. Команды программистов таких компаний, как Google, Square, Amazon, активно ее используют, и у них нет даже мысли о том, чтобы от нее отказаться. В то же время, в большом количестве компаний эту практику или совсем не применяют, или применяют от случая к случаю.

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

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

1. Java Core
2. Junior Java Developer: Servlet API, JDBC, Maven, JUnit, Mockito, Log4J, основы Spring/SpringMVC, основы JPA/Hibernate, шаблоны/архитектуры MVC/IoC/DAO.
3. Multicore programming in Java.

Также я веду курс «Scala for Java Developers» на платформе для онлайн-образования udemy.com (аналог Coursera/EdX).

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

(GolovachCourses.com)

Здесь собраны несколько вариантов записи моего курса Java Core.
Модуль #1 (Procedural Java):
Набор июль 2013: #1, #2, #3, #4
Набор апрель 2013: #1, #2, #3, #4
Набор февраль 2013: #1, #2, #3, #4
Набор январь 2013: #1, #2, #3, #4
Набор октябрь 2012: #1, #2, #3, #4.

Внесу и свой вклад в тренд темного программирования.
Многим из вас знакома дилемма: использовать ли DI в своем проекте или нет.
Поводы перехода на DI:

• создание развитой системы авто-тестов
• повторное использование кода в различном окружении, в том числе в различных проектах
• использование 3rd-party библиотек, построенных на DI
• изучение DI

Доводы не использовать DI:

• усложнение понимания кода (поначалу)
• необходимость конфигурирования контекста
• изучение DI

Допустим, у нас есть большой рабочий проект, принято решение: переводить на DI. Разработчики чувствуют свой потенциал, уровень мидихлориан в крови зашкаливает.

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

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

Полезное для Android разработчика #2

Привет, теперь я постараюсь еженедельно выпускать дайджесты на интересные библиотеки и находки для Ваших проектов.

Сегодня в выпуске

• Android Universal Image Loader
• Android Crop
• Staggered GridView
• FlipView

В этом топике мы хотим поделиться нашим опытом создания мобильных приложений на платформе для разработки кроссплатформенных приложений Titanium. Примерно с 2011 мы начали работы с кроссплатформенными фреймворками. Сначала это был PhoneGap, потом Titanium. Сделали десяток приложений, работающих и по сей день, как в России, так и в США. Мы сознательно хотим отойти от оценок — плохо это или хорошо разрабатывать кроссплатформенные приложения, а сосредоточиться на тех трудностях, с которыми предстоит столкнуться с точки зрения разработки и сопровождения этих приложений.

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

Итак, начнем со списка проблем, с которыми вам придётся столкнуться.

Проблемы:

1. Проблема дабл-кликов.
2. If’ный код.
3. Управление памятью на Android.
4. Недостаточная реализация отдельных функций, в том числе стандартных.
5. Javascript — отсутствие типизации замедляет процесс написания кода и усложняет сопровождение.
6. Отсутствие InterfaceBuilder — замедляет процесс написания приложения, весь UI пишется в коде.
7. Titanium SDK обновляется позже SDK операционных систем.
8. Каждая версия SDK содержит исправление старых ошибок и привносит новые ошибки.

Примеры, на которых мы столкнулись с этими проблемами.

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

Много бороздя по простором Github, я нашел множество интересных проектов, source кодов, и библиотек. И теперь пришло время поделиться ими. Встречайте множество вкусностей под катом!

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

Account

Для начала нам потребуется собственный аккаунт на устройстве. Сначала, я думаю, стоит ответить на вопрос, зачем? Действительно, зачем?

Краткое резюме преимуществ:

• Поддержка фоновых механизмов вроде SyncAdapter
• Стандартизация способа авторизации
• Поддержка различных токенов (прав доступа)
• Шаринг аккаунта с разграничением привилегий (возможность использовать один аккаунт для различных приложений, как это делает Google)

Шаги для получения плюшек:
1) Создание Authenticator'а
2) Создание Activity для логина
3) Создание сервиса для общения с нашим аккаунтом

Java еще не умерла — и люди начинают это понимать.

Добро пожаловать в ведение по Java 8. Этот материал шаг за шагом познакомит вас со всеми новыми фичами языка. Вы научитесь использовать методы интерфейсов по умолчанию (default interface methods), лямбда-выражения (lambda expressions), ссылки на методы (method references) и повторяемые аннотации (repeatable annotations). Все это будет сопровождаться короткими и простыми примерами кода. В конце статьи вы познакомитесь с наиболее свежими изменениями в API, касающихся потоков, функциональных интерфейсов, расширений для ассоциативных массивов, а также с изменениями в API работы с датами.

Вступление

После некоторого перерыва в разработке моего приложения под Android, в течение которого в моей голове формировались все новые и новые идеи, как сделать его красивее и удобнее, в конце января я вновь уселся за разработку. За время размышлений подход к созданию приложения немного трансформировался, и посему до объектной модели я добрался только тройку недель назад. И почти сразу столкнулся с необходимостью доработки UCAOrm. Кому интересно узнать не только об уже внедренных нововведениях, но и о том, что еще только в процессе разработки —

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

Перевод второй главы свободно распространяемой книги Building and Testing with Gradle

Задача (task) является основным компонентом процесса сборки в файле билда Gradle. Задачи представляют собой именованные наборы инструкций билда, которые Gradle запускает выполняя сборку приложения. При сравнении с другими билд-системами, задачи могут показаться знакомой абстракцией. Однако Gradle предоставляет более развитую модель, в отличие от той, которая вам уже может быть знакома. По сравнению с традиционными возможностями объявления операций билда, связанных зависимостями, задачи Gradle являются полнофункциональными объектами, которыми вы при желании можете управлять программно.

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

Дисклеймер

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

Уверен, что мои советы не станут для вас откровением, просто, как это часто бывает, не всегда можно взглянуть на свою работу со стороны и учесть моменты, которые “замыленным взглядом” просто не видны.

Доброго времени суток всем хабражителям. Меня зовут Илья Шакитько и я работаю в LeaseWeb, в команде, работающей над облачными сервисами. Решая очередную задачу, связанную с исследованием той или области, мы стараемся поделиться полученными знаниями или мыслями с сообществом. Не так давно мы проводили DevOps встречу в нашем офисе, где одним из выступающих был мой коллега, Мауритс ван дер Скхи, который рассказывал об API First архитектуре. Немногим ранее в нашем блоге он опубликовал статью, переводом которой я хотел бы поделиться с вами.

Введение

API First архитектура это архитектура, для которой API пользователь является основным пользователем приложения. Это означает, что этот API должен иметь наивысший приоритет, а не быть еще одним представлением (view) в парадигме MVC. Основное различие состоит в том, что API First требует наличия полного, адаптивного и хорошо документированного API. Это особенно важно в таргетировании: на мобильных платформах (приложения используют API), у реселлеров (слой представления использует API) и в многопродуктных средах с высокой интеграцией, но малой связанностью.

Однажды на Хабре нашел статью об алгоритме поиска слов в игре балда: habrahabr.ru/post/207734 Я сам являюсь автором решателя «Робот Балда 2», который за многие годы приобрел популярность у многих онлайн игроков в игре Балда. И я хотел бы то же поделиться своим опытом и рассказать об одном уникальном алгоритме в игре балда, который еще ни кем не применялся.

Цель статьи: хочу поделится опытом создания трех вычислительных кластеров Matlab, а также их удаленного администрирования.

Небольшое вступление

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

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

Итак, обо всем — по порядку

Железо в наличии:

Дома: комп (Phenom II x4 840, 7x64) и ноут (Athlon II Dual-Core M320, 7x64) соединенные в одну сеть старым добрым маршрутизатором DIR-300.

Дома у девушки: комп (i5 4440, 7x64).

На работе: 10 компов (Athlon II Dual-Core, XPx86) (связанных в одну сеть) в одном помещении и 4 (Athlon II Dual-Core, XPx86) в другом (тоже связанных в одну сеть). Локальной сети между помещениями нет.

На всех вышеперечисленных ящиках присутствует доступ в интернет.

Добрый день, хабровчане. Сегодня я хотел бы рассказать о Location APIs в общем и о геозонах (geofences) в частности, которые были представлены на Google I/0 2013 (видео и презентация). Не смотря на то, что событие произошло более полугода назад, на хабре до сих пор нет вменяемой информации об этом (только одно упоминание). Постараюсь немного исправить ситуацию.

Думаю, многие из нас писали код вида:

    @Override
    public boolean onTouch(View view, MotionEvent event) {
        final float x = event.getX();
        final float y = event.getY();
        // использование x и y...
        return false;
    }

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

Год назад я с друзьями разрабатывал приложение, где очень многое упиралось в обработку касаний. Однажды, загрузив новые исходники из репозитория и собрав приложение, я обнаружил, что вертикальная координата касания определяется неверно. Просматривая последние коммиты команды, я наткнулся на интересную строку, где внезапно от y-координаты отнималось 100. То есть, что-то вроде «y -= 100;», причем, это число не было вынесено как константа и вообще было непонятно почему именно 100. На мой очевидный вопрос я получил ответ «Ну, мы опытным путем определили, что в этом месте y-координата всегда на 100 (пикселей) больше, чем должна быть». Здесь, конечно, стоило бы перечитать документацию по обработке касаний и, просмотрев код проекта, найти ошибку, но я решил пойти более интересным путем – проследить по исходникам Android за MotionEvent от его получения до утилизации.

Если я смог кого-то заинтриговать историей в стиле «По следам полосатого бага» — добро пожаловать под кат.