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

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

Предлагаю вашему вниманию устройство для автоматического полива цветов на базе микроконтроллера Attiny13a, подробности под катом.

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

Знакомится будем на примере фреймворка akka используя язык java (сам akka написан на scala).

Предисловие к FAQ.

Программирование является моим хобби уже давно (правда на других языках и платформах), но до андроида руки дотянулись совсем недавно. Прошло несколько этапов, прежде чем я добрался до написания программ.
Сначала была пара месяцев посвященных Java, на сайте с «Сгибателем».
После, долгие попытки подружится с Eclipse, закончившиеся побегом на Android Studio.
На данный момент выпущено 7 программ и две находятся в разработке.
Данная подборка возникла как попытка структурирования и оптимизации полученной в процессе информации.
Заранее извиняюсь за возможно некорректную терминологию – так как практикую обучение через создание, и в теоретической части есть пробелы.

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

Прежде чем начать рассказ про наш очередной opensource-инструмент, давайте я поясню, для чего мы его сделали. Я довольно много общаюсь с коллегами-тестировщиками и разработчиками из разных компаний. И, по моему опыту, автоматизация тестирования ─ один из самых непрозрачных процессов в цикле разработки ПО. Посмотрим на типичный процесс разработки функциональных автотестов: ручные тестировщики пишут тест-кейсы, которые нужно автоматизировать; автоматизаторы что-то делают, дают кнопку для запуска; тесты падают, автоматизаторы разгребают проблемы.



Я вижу здесь сразу несколько проблем: ручные тестировщики не знают, насколько автотесты соответствуют написанным тест-кейсам; ручные тестировщики не знают, что именно покрывается автотестами; автоматизаторы тратят время на разбор отчётов. Как ни странно, но все три проблемы вытекают из одной: результаты выполнения тестов понятны только автоматизаторам — тем, кто эти тесты писал. Именно это я и называю непрозрачностью.

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

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

Недавно Apple представила общественности достаточно важное изменение в разработке iOS приложений, анонсировав новый язык программирования Swift. В настоящее время, количество материалов на русском, посвящённых этому языку, ограничено. Также Swift — язык объектно-ориентированный, и классы в нём — основа основ. Поэтому я решил перевести эту статью.

Что самое ужасное в случае удаления приложения? Правильно, потеря связи с аудиторией и невозможность проинформировать о том, что у приложения сменился адрес прописки и имя пакета. Задачу решают Push уведомления, но это довольно хлопотно и не всегда удобно. А иногда и дорого.



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

Недавно мне пришлось поработать с библиотекой Google Gson, предназначенной для преобразования Java-объектов в текстовый формат JSON (сериализация) и обратного преобразования (десереализация). Часто при работе с Gson хватает стандартных настроек библиотеки, но бывают случаи (в том числе мой), когда необходимо кастомизировать процессы преобразований.

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

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

Меня зовут Юрий Леонычев. Я работаю в службе информационной безопасности Яндекса, где разрабатываю интересные сервисы, комбинирующие методы машинного обучения с анализом BigData. Как вы знаете, у Яндекса большое количество мобильных приложений. И если безопасностью наших веб-приложений мы занимаемся уже давно, то мобильным часто уделялось недостаточно внимания. Частично это было связано с тем, что мобильные приложения считались продолжением своих «больших» братьев, надстройками над WEB API.



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

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

Предисловие

Недавно Apple представила общественности достаточно важное изменение в разработке iOS приложений, анонсировав новый язык программирования Swift. Я принял решение: изучая этот язык пошагово, я буду в своих статьях рассказывать обо всём, что мне удалось найти. Это лишь первый пост из многих на эту тему, но я надеюсь, что вы решите изучать язык вместе со мной!

Весьма вероятно, что многие примеры кода, представленные в постах, будут позже изменены. Это отчасти потому, что мой стиль программирования – написать сейчас, чтобы проверить идею, а потом заняться рефакторингом, а также отчасти это потому, что для меня (как и для многих других) Swift – абсолютно новый язык программирования. Так что, скорее всего, как только я узнаю что-нибудь новое, ход этих уроков будет меняться.

Итак, я собираюсь начать с довольно простого приложения. Также я буду объяснять, как работает код. Готовы? Поехали…

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

Осенью 2013 года я дважды на конференциях (сначала SECR, потом ConfeT&QA) рассказывал о том, как происходило развитие инструмента Selenium и каково текущее состояние дел. Предлагаю вашему вниманию запись, сделанную на второй из упомянутых конференций.

Года два назад я обнаружил, что в Android Market нет удобных мне приложений для учета времени, затраченного на разные проекты. Как настоящий лентяй, я решил не искать требуемое, а написать его сам. Это оказалось несколько сложнее, чем казалось вначале, и я все забросил в режиме вялотекущего хобби воплощение моего желания прожило больше года, медленно продвигаясь от идеи к альфа-версии.

И тут вдруг добрые люди предложили мне рассказать, как писать под Android на Kotlin'e. Мне показалось, что это добрый знак, и я быстро переписал приложение на Kotlin, закончил его и выложил в Google Play.

Важное уточнение: эта статья — только про то, как писать под Android на Kotlin'e. Интересно будет только тем, кто хочет попробовать Kotlin, и тем, кто хочет понять, зачем его пробовать. Приложение, которое я написал — очень-очень простое (и само по себе никак не относится к JetBrains). В его коде гарантированно можно что-то улучшить, оно выложено на Github только для примера, а не в качестве образца восхитительного кода. Оно работает, и если вам хочется его попробовать, то поставить можно отсюда. Но еще раз: это — демо, его цель — быть не совершенным приложением, а введением в Kotlin под Андроид.

Опять что-то новое. И зачем мне это знать?

Продолжаем публиковать e-Lectures — видео-лекции от мобильных разработчиков e-Legion.

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


Презентация

Демо-проект на github: github.com/stepango/support_library_21_demo

Здравствуй, Хабр! Мне хотелось бы поделиться историей о создании велокопомпьютера своими руками. После покупки велосипеда я решил как-то фиксировать свой прогресс, но мобильные трекеры оказались не самым удобным решением, а из Китая ко мне уже летел заранее заказанный там BOGEER 823, что делало покупку на месте бессмысленной. Поэтому я решил попытаться сделать велокомп своими руками, заодно заложив в него основу для расширения: управление обвесом велосипеда (передний и задний свет, звонок).

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

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

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

Из-за простоты необходимых мне возможностей я остановился на PIC, но коллега вовремя наставил меня на путь праведный и сказал копать в сторону STM и AVR, так как себестоимость не на много больше а возможности на порядок выше.

И вскоре я приобрел отладочную плату STM32F4 Discovery kit for STM32F407

В первый день носился с ней по дому и радовался как мигают LEDы и работает гироскоп. Но пора бы начать и самому писать программы. После 30 минут гугления я понял что 95% решений описанных в интернете работают под Windows, а счастливые обладатели Linux и Mac OS гуляют лесом. Я провел 3 дня по вечерам в поисках решений и в итоге имеем полный мануал как начать программировать под STM32 под Mac OS.

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

Свела как-то судьба начинающего программиста и начинающего электронщика вместе. И начали они творить. Сделали они сдесяток небольших игрушек-мишек с записывающими звуковыми модулями и поняли, что использовать однофункциональные платы не так уж и весело. И вот светлыми летними вечерами они собирались и думали, что бы им такого интересного сделать? Судьба помогла им и во второй раз: они нашли объявление о продаже отладочной платы STM32VLDiscovery в России и уже через неделю трясущимися руками распаковали посылку и «поморгали» светодиодами. От ощущения полной власти над крошечным устройством загорелись глаза и заработали мозги. Было решено: сделать «электронный браслет» с каким-нибудь интересным функционалом, используя весь потенциал их новой «игрушки»…

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

Отзывчивость, простота, гибкость и расширяемость кода — принципы, которые можно закрепить за реактивным UI.

Наверняка, если совместить реактивные backend и UI, то можно получить качественный продукт. Именно его мы и попытались сделать, разрабатывая 2GIS Dialer — звонилки, которая работает через API и при этом должна оставаться быстрой и удобной.

Баста карапузики, кончилися танцы.

В предыдущей части мы детально рассмотрели «читерские» приёмы обхода «защит» (скрытие SSID, MAC-фильтрация) и защит (WPS) беспроводных сетей. И хотя работает это в половине случаев, а иногда и чаще — когда-то игры заканчиваются и приходится браться за тяжёлую артиллерию. Вот тут-то между вашей личной жизнью и взломщиком и оказывается самое слабое звено: пароль от WPA-сети.

В статье будет показан перехват рукопожатия клиент-точка доступа, перебор паролей как с помощью ЦП, так и ГП, а кроме этого — сводная статистика по скоростям на обычных одиночных системах, кластерах EC2 и данные по разным типам современных GPU. Почти все они подкреплены моими собственным опытом.

К концу статьи вы поймёте, почему ленивый 20-значный пароль из букв a-z на пару солнц более стоек, чем зубодробительный 8-значный, даже использующий все 256 значений диапазона.

Оглавление:
1) Матчасть
2) Kali. Скрытие SSID. MAC-фильтрация. WPS
3) WPA. OpenCL/CUDA. Статистика подбора

Так получилось, что какой бы ни был аккуратный микрорайон, он всегда с чем-нибудь соседствует, плюс всегда есть праздношатающиеся, непраздношатающиеся и «этождети». Это если забыть про наркоманов, целенаправленных воров и разбойников. Твой дом — твоя крепость. Подъезд твоего дома — тоже твой дом. (Да, этот пункт многие не понимают, но учиться никогда не поздно). Классические методы защиты подъезда — установка укреплённых дверей; установка домофона; инсталляция консьержки; организация видеонаблюдения над входами.

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

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