На картинке первая мысль читателя, который недоумевает, что можно написать про такую простую задачу как отображения диалога. Аналогично думает и менеджер: «Тут ничего сложного, наш Вася за 5 минут сделает». Я, конечно, утрирую, но на самом деле всё не так просто, как кажется на первый взгляд. Особенно если мы говорим про Android.

Итак, на дворе шёл 2019 год, а мы всё ещё не умеем нормально показывать диалоги.

Realm давно известен в среде мобильных (и не только) разработчиков. К сожалению, в рунете почти нет статей об этой базе данных. Давайте исправим эту ситуацию.

Год назад в build.gradle нашего проекта появилась строчка:

classpath "io.realm:realm-gradle-plugin:0.87.5" 

За этот год код Realm вырос до версии 3.3, обзавелся множеством фич и починил кучу багов, реализовал новый функционал и получил облачный бекенд. Давайте поподробнее поговорим о Realm в реалиях Andoroid разработки и обсудим тонкие моменты, возникающие при его использовании.

Привет, Хабр! В этой статье я расскажу о результатах публикации одной визуальной новеллы и поведаю о второй, при разработке которой я попытался учесть полученный опыт…
Перед интенсивной разработкой небольшой игры (aka хакатоном) важно решить чего вы хотите: программировать, повеселиться или создать готовый продукт? У меня есть друг, который очень хочет сделать игру, но раз за разом он начинает с создания графического движка, на базе libgdx. Возможно, такой путь приводит к шедеврам вроде {$TitleCoolIndieGame}. На мой же взгляд, ему просто хочется попрограммировать. Так, что Читатель, если же Вы действительно хотите сделать игру, лучше не начинать с абсолютного нуля или читать эту статью, а приступить к конкретной работе! Тем более, что под катом не success story, а согласование макетов полуголой девушки, вакуумные маффины в коне, безумная работа над переводом сомнительного юмора и ещё более сомнительных отсылок, описание ненормальной соло разработки, да немного программирования, чтобы соответствовать тематике.
Под катом десяток мегабайт графики и более десяти страниц текста.

От переводчика: некоторые скорее всего уже читали этот титанический труд от Мартина Фаулера и его коллеги Джеймса Льюиса, но я все же решил сделать перевод этой статьи. Тренд микросервисов набирает обороты в мире enterprise разработки, и эта статья является ценнейшим источником знаний, по сути выжимкой существующего опыта работы с ними.

Термин «Microservice Architecture» получил распространение в последние несколько лет как описание способа дизайна приложений в виде набора независимо развертываемых сервисов. В то время как нет точного описания этого архитектурного стиля, существует некий общий набор характеристик: организация сервисов вокруг бизнес-потребностей, автоматическое развертывание, перенос логики от шины сообщений к приемникам (endpoints) и децентрализованный контроль над языками и данными.

А нужен ли PCI DSS?

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

PCI DSS — это стандарт безопасности, который применяется для всех организаций сферы обработки платежных карт: торговых точек, процессинговых центров, финансовых учреждений и поставщиков услуг, а также других организаций, которые хранят, обрабатывают или передают данные держателей карт и (или) критичные аутентификационные данные.

Стандарт PA-DSS распространяется на поставщиков приложений и иных разработчиков приложений, которые хранят, обрабатывают или передают данные держателей карт и (или) критичные аутентификационные данные.

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

С мобильным приложением все немного сложнее.

Всем привет! Данная статья является переводом заметки Android-разработчика и автора книги «Android 4. Программирование приложений для планшетных компьютеров и смартфонов» Рето Майера. Над переводом работал Android-отдел компании Лайв Тайпинг. Оригинальная статья доступна здесь.

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

Взять, к примеру, Instant Run. Это фича Android Studio, которая при помощи «магии» сокращает время, затрачиваемое на сборку и деплой инкрементальных изменений кода в процессе написания / тестирования / дебаггинга.

Я называю это магией потому, что со стороны всё выглядит именно так. После первого нажатия Run или Debug всё работает так, как того и следует ожидать. Однако каждый раз, когда в код вносятся изменения и снова нажимается кнопка Run или Debug (но в этот раз — с иконкой в виде молнии), изменения деплоятся на мой телефон настолько быстро, что я не успеваю это заметить.

В нашем блоге на Хабре мы не только рассказываем о развитии своего продукта — биллинга для операторов связи «Гидра», но и публикуем материалы о работе с инфраструктурой и использовании технологий.

Недавно мы писали об использовании Clojure и MongoDB, а сегодня речь пойдет о плюсах и минусах денормализации баз данных. Разработчик баз данных и финансовый аналитик Эмил Дркушич (Emil Drkušić) написал в блоге компании Vertabelo материал о том, зачем, как и когда использовать этот подход. Мы представляем вашему вниманию главные тезисы этой заметки.

В Edison мы часто сталкиваемся с оптимизацией мобильных приложений и хотим поделиться материалом, который считаем крайне полезным, если вы решаете одну из двух задач: а) хотите чтобы приложение меньше тормозило; б) хотите сделать красивый, мягкий и гладкий интерфейс для массового пользователя.
Предлагаем вашему вниманию первую часть перевода статьи Udi Cohen, которую мы использовали как пособие для обучения молодых коллег оптимизации под Android.



Несколько недель назад я выступил на Droidcon в Нью-Йорке с докладом об оптимизации производительности Android.

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

Мои основные правила, которым я следую при работе с оптимизацией:

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

До создания серьезных приложения со сложной структурой View и Layout'ов мы особо не задумывались над тем, как простые и логичные действия в стиле «смотрите, я набросал дизайн из лэйаутов» могут серьезно замедлить работу всей программы.

Помимо прочего, задача с «Короной Эмбера» осложнялась еще и тем, что игра, которую мы задумали перенести на Андроид платформу, была сама по себе достаточно насыщенной различными компонентами, которые как-то надо было умещать на игровом поле или рядом с ним.

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

В первой части статьи рассматривались структуры execution context, lexical environment и объекты Function. Вторая часть посвящена использованию this.

Про устройство JavaScript написано много статей. В первую очередь, это "JavaScript. Ядро." Дмитрия Сошникова, перевод статьи Ричарда Корнфорда и поста Дмитрия Франка. Но для того чтобы хорошо разобраться в какой-либо технологии лучше обратиться к первоисточникам. В данном случае к стандарту ECMA-262 ECMAScript Language Specification. Я рассматриваю этот пост как облегченный способ начать изучение стандарта. Рекомендую переходить по ссылкам, вчитываться в текст спецификации и составлять собственные схемы.

Начнем с важной информации: совсем не обязательно перспективные языки являются новыми. Им не так много лет, как вашим любимым Python или Ruby, их нет ни в одной топовой десятке популярных рейтингов (GitHut, RedMonk, TIOBE Index), а знание этих языков не дает пока существенной прибавки к зарплате (за исключением, возможно, Swift). Но и назвать их революцией, набирающей обороты в среде избранных, тоже нельзя. Безусловно, у них есть своя ниша, определенная доля рынка (до 2%) и сложившееся комьюнити. Просто в будущем именно они могут посягнуть на лавры топ-5, если не случится событие типа «черный лебедь».

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

Многим знакомо чувство, когда чувствуется энергия от той самой идеи, что позволит свернуть горы и разработать законченное приложение, а не пополнить кладбище недоделок. Я по доброму завидую тем людям, что умеют трезво рассчитывать свои силы, а не увязать в трясине под гнётом рутины. У меня хватало сил, чтобы не дать начать себе что-то новое… Но конечно, разработка больших и длинных хобби проектов «потому, что бросить» жалко тянет соки, а не приносит радость. Эта публикация о том, как я намеренно дал слабину, чтобы поднять себе настроение, разработав простую игру за три дня. И сделал её за неделю, потратив десять маффинов, но получив кучу опыта и хорошего настроения.

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

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

Я смирился с мыслью, что мой лучший код уже написан — в прошлом. Мне было уже 54 года (немало!) и я, вероятно, уже не мог писать код так же хорошо, как и раньше. Кто знает — может быть у меня уже начала отказывать память, ну или я просто выучил всё, что был способен в жизни выучить. Мой настрой подкреплялся наблюдениями окружающей меня реальности. Все новые технологии выглядели для меня чудаковато. Я ненавидел Node.js. Я считал все фреймворки для веб-разработки ужасными. И я сетовал на то, что классические способы разработки ПО разрушились и превратились в набор клише, которые нынче впариваются под умными названиями типа Agile или «экстремальное программирование». Я скучал за днями, когда люди писали спецификацию на будущее ПО, программировали, а затем тщательно тестировали его. И когда в каждой статье не было тысячи жаргонных словечек.

Хочу поделиться с вами своим опытом разработки с нуля системы внутрикорпоративного менеджмента чатов и аудио/видео записей. Дело было поболее года назад. Забегая вперёд, хочу с огорчением сказать, что сейчас проект заморожен. Кризис ли, потеря веры в проект руководством или еще какие-то причины — мне неизвестно. Хотя коллектив был приятный, решать задачи было интересно и увлекательно. Я вообще люблю постановку задач в духе: “У нас есть вот такой набор данных, но мы не знаем как это должно выглядеть. Вот, возьми карандаш и изобрази нам чего-нибудь”. И сотрудничество с ними идеально попало под такой формат.

Developer Economics — это самое большое в мире исследование, посвященное мировым трендам в области экономики приложений и мобильной разработки. Основано оно на опросе разработчиков и компаний, который проводит британская компания VisionMobile раз в полгода.

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



Полсотни респондентов постарались максимально охватить все актуальные темы IT-современности. Мы говорили про языки и методы программирования, делились опытом трудоустройства, тимлидинга и создания собственных компаний, немного сплетничали и вполне серьёзно рассуждали о перспективах цифрового мира. Итак, обо всём по порядку.

Карьера

Вопросы построения карьеры обсуждались на конференции, пожалуй, наиболее часто. Безусловно, этому поспособствовала ситуация в стране и мире, но и уровень гостей в не меньшей степени располагал к очевидным вопросам о том, как достигнуть таких же успехов. Иван Немытченко из Skillgrid посоветовал не гордиться лишь одним университетским дипломом, а прямо во время обучения стремиться применять навыки в реальном мире. Владимир Железняк из IT-Boost и Иван Бут (ex-Google) затронули тему прохождения собеседований в крупных компаниях и задали ключевой вопрос: «а надо ли вам это?». <a href=«geekbrains.ru/events/158?

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

Есть очень неплохая книжка о специфике работы русских вообще. Она называется «Русская модель управления». Ее написал А.П.Прохоров (другой, не олигарх). Не буду ее пересказывать. Основная идея в том, что русские по своей природе могут работать только в двух модах. В нестабильном состоянии они могут свернуть горы. В это время мотивация очень высокая. В стабильном расслабленном состоянии — когда никто не пинает — русские вроде как работают плохо и не сильно утруждаются.

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

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

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

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

Некоторые могут возразить, что следование гайдам может убить творчество, и в итоге все приложения будут выглядеть одинаково. С точки зрения UX, я тут вижу другую проблему. Может казаться, что применение лучших шаблонов, которые используют Google / Facebook / Instagram / [вставить любимое приложение], всегда является отличным решением. Что они ставят себе такие же задачи, что и вы. Вот несколько шаблонов, которые считаются (или считались) лучшими, но в то же время не такие уж они и хорошие, какими кажутся на первый взгляд.

На прошлой неделе JetBrains объявила о выходе IntelliJ IDEA 15. Как всегда, IDE доступна в двух редакциях: коммерческая Ultimate и бесплатная Community Edition. Скачать новую версию можно на официальном сайте JetBrains. Этот пост вкратце о том, что в ней нового и интересного.



Kotlin
Главная новость заключается в том, что одновременно с релизом IntelliJ IDEA 15 вышел и Kotlin Beta — практически готовый к релизу JVM язык программирования, разрабатываемый в недрах JetBrains. В IntelliJ IDEA 15 поддержка Kotlin доступна “из коробки”.

Отладчик
Популярность Java 8 продолжает набирать обороты, а JetBrains продолжает делать отладчик более удобным для работы с лямбда-выражениями. При добавлении точки останова IDE теперь позволяет выбрать конкретное выражение. Перейти в конкретное лямбда-выражение теперь можно и при помощи Step Into и Run to Cursor.

Также в отладчик был добавлен инструмент Force Return. Он позволяет прервать исполнение текущего метода и вернуть выбранное значение. Это может быть удобно, если вы хотите поменять логику выполнения программы без изменения кода и без перезапуска.