Kotlin *

Встречайте, Siesta 1.0 - аналог One UI на любом Android девайсе!

One UI существует уже как 3 года (с 2018), а уроков по тому, как сделать похожий дизайн, в мире android, я так и не нашёл. Не порядок… Сегодня же, мы начнём прокладывать этот тяжёлый и тернистый путь.

Меня зовут Сергей, я тимлид команды андроид Тинькофф. 

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

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

Здесь я хочу рассказать о том, что мы имели ДО и что получилось сейчас. 

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

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

В нашем примере кредитный шлюз эмитирует событие о создании займа. Служба предоставления займов прослушивает его и выполняет дальнейшую обработку. В случае коммуникации на основе Http видно, что фреймворк Pact запускает имитатор Http-сервера. Коммуникация на основе сообщений отличается от Http тем, что не существует единого стандартного способа коммуникации. Она может быть организована с помощью различных инструментов, таких как Kafka, RabbitMQ, ActiveMQ и т.д. Pact может не связываться с этими инструментами, и, поэтому, он не запускает ни один из них во время выполнения тестов, а просто позволяет нам убедиться, что потребитель и производители событий придерживаются одной и той же схемы. В конечном итоге это то, что нам нужно! Давайте перейдем к коду.

Потребительский тест

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

Привет, Хабр! На написание этого поста меня вдохновил другой пост TDD есть опиум для народа, где обсуждаются спорные моменты в подходе TDD и в принципе делается вывод о его несостоятельности (хотя и признается необходимость тестов в любом случае). С автором я был полностью согласен... раньше, пока не понимал действительную суть TDD. Поэтому, я счел своим долгом рассказать суть Test Driven Development от лица человека, который пробовал писать тесты до реализации, разочаровался из-за сложностей, и только через некоторое время, уловив основную мысль, увидевшего новые возможности в разработке через тестирование.

Замечание: я всего лишь junior, и опыта разработки у меня не так много. Но надеюсь, что мне удастся донести мысль до читателя, а ошибки помогут исправить в комментариях. Примеры будут на Kotlin, мне кажется, это не должно стать помехой, язык достаточно хорошо читаемый. Несмотря на довод о слишком упрощенных примерах (наподобие калькулятора) в оригинальной статье, здесь я также не иду в дебри реальных повседневных задач, ограничиваясь кустарным примером. Да простит меня читатель, я не хочу заставлять сильно вникать в код, хочу просто объяснить идею.

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

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

Привет!

Это будет наш первый митап, посвященный разработке на Android. Бесплатно, можете как приходить лично (Москва, 2-й Кожуховский проезд, д.29 корп. 6. LOFT HALL №4 (Зал Andy Hall)), так и подключаться онлайн. Если решите прийти лично, главное — зарегистрироваться заранее.

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

Всего будет 7 спикеров, среди которых специальный гость — Илья Линник, человек, работающий с Android более 10 лет и заставший первые API.

Меня зовут Дмитрий, я специалист по тестированию в студии IT Territory. За 17 лет мы выпустили более 15 успешных игровых проектов с общей аудиторией около 100 млн игроков по всему миру. Вы можете быть знакомы с нами по таким проектам, как Аллоды Онлайн, Hawk, Space Justice, World Above, Rush Royale. И в этом посте я расскажу о том, как мы проводим нагрузочное тестирование игровых серверов.

Невозможно представить JPA без сущностей. Однако, их определение в Котлине таит некоторое количество подводных камней. Давайте посмотрим, как избежать распространенных ошибок и использовать возможности Котлина на максимум. Внимание спойлер! Классы данных — не лучший вариант для сущностей.

В этой статье основное внимание будет уделено Hibernate, поскольку он является несомненным лидером среди всех реализаций JPA.

Многие мобильные приложения уже могут конкурировать с полноценными десктопными вариантами, а иногда и превосходить их. Офисные пакеты, фоторедакторы и IDE вполне неплохо работают на портативных девайсах. Samsung, например, даже сделал специальный режим DeX Mode, который позволяет подключить к смартфону монитор и периферию.

А скорый релиз Windows 11 с возможностью устанавливать любые APK-файлы прямо намекает, что пора озаботиться поддержкой десктопных режимов в своих мобильных приложениях. Один из шагов к этому — добавить полноценную поддержку клавиатуры, чем сегодня и займёмся.

Под катом разберём навигацию по RecyclerView, привязку горячих клавиш к toolbar menu, добавим кастомные сочетания и покажем пользователям, как ими пользоваться.

Kotlin Multiplatform Mobile позволяет компилировать Kotlin код в нативные библиотеки для Android и iOS. И если в случае с Android полученная из Kotlin библиотека будет интегрироваться с приложением написанным на Kotlin, то для iOS интеграция будет с Swift и на стыке Kotlin и Swift, из-за разницы языков, происходит потеря удобства использования. В основном это связано с тем, что компилятор Kotlin/Native (который компилирует Kotlin в iOS framework и является частью Kotlin Multiplatform) генерирует публичное API фреймворка на ObjectiveC, а из Swift мы обращаемся к Kotlin за счет этого сгенерированного ObjectiveC API, так как Swift имеет интероп с ObjectiveC. Далее я покажу примеры ухудшения API на стыке Kotlin-Swift и покажу инструмент, который позволяет получить более удобное API для использования из Swift.

Внимание, статья содержит довольно много картинок и получилась довольно тяжелой и объемной

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

В данной статье будут рассмотрены только основы Java Bytecode. Если вы уже знакомы с его основами, статья вряд ли будет вам интересна.

Это первый блог из серии о тестированиях контракта потребителя сервиса. В этой серии представлена концепция и продемонстрировано написание тестов контрактов для приложения spring boot.

В мире микросервисов мы часто говорим об их преимуществах. Однако есть определенные условия, которые должны быть соблюдены, прежде чем выбрать этот архитектурный паттерн. Блог Мартина Фаулера очень хорошо освещает эти требования. Одним из условий, о которых он упоминает, является ContinuousDelivery. ContinuousDelivery — это технология разработки программного обеспечения, при которой вы создаете его таким образом, что оно может быть запущено в любое время. В контексте микросервисов непрерывная доставка (continuous delivery) означает, что любой сервис может быть внедрен в производство в любое время вне зависимости от остальных микросервисов. Но что гарантирует, что развертывание нового микросервиса не повлияет на общую функциональность приложения? Конечно, тестирование. Однако мы не хотим запускать все приложение, которое может состоять из сотен микросервисов, только для того, чтобы протестировать крошечное изменение кода в одном из сервисов. Так что же нам делать?

Прежде чем решать проблему, давайте сделаем шаг назад. Зачем нам нужны другие микросервисы для тестирования крошечного изменения кода в одном из сервисов? Ответ заключается в том, что сервисы взаимодействуют друг с другом для достижения общей цели. И нам нужно убедиться, что изменение кода не нарушит существующую функциональность. На самом деле достаточно убедиться, что изменение кода не повлияет на API сервиса. Если API сервиса не поврежден, то можно с уверенностью предположить, что потребительские микросервисы этого конкретного сервиса будут работать правильно. Так мы можем избежать запуска всего приложения для тестирования изменений в сервисе. Но каким способом будет проверяться целостность API сервиса? Ответ — с помощью тестирования контракта. Давайте рассмотрим простой пример, чтобы лучше это понять.

Полезная библиотека Pebble Templates и как с ней готовить.

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

Вышел наш летний релиз — IntelliJ IDEA 2021.2! Обновление можно скачать с нашего сайта или в Toolbox App. Кроме того, можно обновиться из самой IDE или с помощью snap-пакета, если вы являетесь пользователем Ubuntu.

Инъекция зависимостей во ViewModel — очень популярная тема для статей по всему интернету. Давайте посмотрим, какие проблемы могут скрывать популярные подходы, и разберемся, есть ли способ инжектить ViewModel с помощью Dagger без огромного количества кода или потерь валидации графа зависимостей во время компиляции.

С релизом Android 12 приложения, где новая версия операционки будет указана в targetSdkVersion, получат запрет на запуск foreground-сервисов в бэкграунде. В качестве альтернативы Google предлагает WorkManager, который с появлением expedited jobs станет предпочтительным вариантом для запуска высокоприоритетных фоновых задач. 

О нём и пойдёт речь в статье — под катом обсудим новые возможности инструмента, подключим его к приложению и реализуем миграцию с foreground-сервиса.

Настало время разобраться с интересной библиотекой Hilt, которая построена на базе Dagger, и которую рекомендует использовать https://developer.android.com при создании различных зависимостей в вашем проекте. Рассмотрим как можно безболезненно внедрить её в ваш проект, работающий на архитектуре MVVM и использующий Retrofit.