Kotlin *

Предлагаем продолжить добрую традицию Ask me anything на Хабре и поговорить про разработку Android-приложений. Сегодня и завтра Android-команда Badoo будет на связи и ответит на любые вопросы о разработке и тестировании приложений с многомиллионной аудиторией, даст советы начинающим и расскажет про особенности платформы. Если вы столкнулись с какой-то проблемой или у вас есть вопрос по теме, пишите нам!



Обещаем ответить на все комментарии первого уровня, которые появятся здесь до 16:00 17 июля по московскому времени, а по возможности — и на более поздние.

Немного фактов о нас. Badoo и Bumble — одни из самых популярных дейтинг-сервисов в мире: только в Google Play у нас 210 млн скачиваний. В Android-приложениях больше 1,3 млн строк кода. В Android-команде больше 20 разработчиков. Основной язык разработки — Kotlin, архитектурные паттерны — MVI и RIBs, база данных — SQLite.

Под катом — подробнее о нашей команде и о темах, на которые мы можем поговорить.

UPD: Мы завершаем AMA и прощаемся. Спасибо всем за вопросы!

Перевод статьи подготовлен в преддверии старта курса «Backend-разработка на Kotlin»

---

В этой статье мы поговорим о том, как создать простое приложение на Spring Boot с Kafka и Kotlin.

Заявленный в заголовке Kotlin больше ассоциируется с Android-разработкой, но почему бы не поэкспериментировать? Мы с его помощью нашли способ немного упростить автоматизацию тестирования API одного из наших сервисов, а также облегчить работу тестировщикам, мало знакомым с программированием и нюансами языка Java.

Чем мы занимаемся? Разрабатываем сервис для отправки брокерских анкет для расчёта и получения решения по ним. И несмотря на то, что это банковское решение, разработку ведёт небольшая scrum-команда, тестированием в которой занимаются 1-2 специалиста в зависимости от загрузки и ситуации на проекте.

Под катом расскажем о результатах наших экспериментов, которые мы с удовольствием перенесли в продакшн.

Это вторая из трёх статей о применении архитектурного шаблона MVI в Kotlin Multiplatform. В первой статье мы вспомнили, что такое MVI, и применили его для написания общего для iOS и Android кода. Мы ввели простые абстракции, такие как Store и View, а также некоторые вспомогательные классы и использовали их для создания общего модуля.

Задача этого модуля — загружать ссылки на изображения из Сети и связывать бизнес-логику с пользовательским интерфейсом, представленным в виде Kotlin-интерфейса, который должен быть реализован нативно на каждой платформе. Именно этим мы и займёмся в этой статье.

Мы будем реализовывать специфичные для платформы части общего модуля и интегрировать их в iOS- и Android-приложения. Как и прежде, я предполагаю, что читатель уже имеет базовые знания о Kotlin Multiplatform, поэтому не буду рассказывать о конфигурациях проектов и других вещах, не связанных с MVI в Kotlin Multiplatform.

Обновлённый пример проекта доступен на нашем GitHub.

В одном из старых проектов в кучу были навалены ассерты из JUnit, kotlin.test и AssertJ. Это было не единственной его проблемой: его вообще писали как письмо Дяди Федора, а времени остановиться и привести к единому виду не было. И вот это время пришло.

В статье будет мини-исследование про то, какие ассерты лучше по субъективным критериям. Хотел сначала сделать что-то простое: накидать набор тестов, чтобы быстренько копипастом клепать варианты. Потом выделил общие тестовые данные, некоторые проверки автоматизировал, и как поехало все… В результате получился небольшой розеттский камень и эта статья может пригодится вам для того, чтобы выбрать библиотеку ассертов, которая подойдет под ваши реалии.

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

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

Данная статья о проблеме и анализе вариантов её решения. Я не дам вам серебряную пулю против всех монстров, но покажу, как можно изучить конкретного, чтобы создать пулю специально для него. Разберу это на примере того, как мы подружили анимацию смены фрагментов с Bottom Sheet.

О том, как распутать джунгли MVI, используя Джунгли собственного производства, и получить простое и структурированное архитектурное решение.

Всем привет!

Меня зовут Антон Князев, senior Android-разработчик компании Omega-R. В течение последних семи лет я профессионально занимаюсь разработкой мобильных приложений и решаю сложные проблемы нативной разработки.

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

И снова здравствуйте. В преддверии старта нового курса «Backend-разработка на Kotlin», мы подготовили для вас перевод статьи, в которой рассказывается о том, чем же Kotlin отличается от Java.

---

«Kotlin – новый язык программирования, который заставит вас отказаться от Java». На европейской конференции Zebra APPFORUM 2017 в Праге наш Android-разработчик Питер Оттен вдохновлял других начать писать на Kotlin. Расстроены, что пропустили? Не переживайте! Питер расскажет вам, почему он стал большим поклонником этого языка.

Подъем

Kotlin – это язык программирования, разработанный компанией Jetbrains, которая знаменита IntelliJ, WebStorm, PhpStorm и плагином ReSharper для Visual Studio. Они занялись поисками нового языка программирования, который был бы лучше, чем Java, но все еще функционально совместим с ним. Вдохновляясь языками Java, C#, Scala и Groovy, ребята из Jetbrains собрали команду для разработки нового языка программирования. Kotlin проектировался людьми, которые испытали всю боль Java.

Дзень добрый, комрады.

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

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


Чтобы быстрее получить результат, упростим наши требования к музыке.

Будем строить наш трэк из трёх компонентов:

• Перкуссия
• Бас
• Мелодия

И будем сравнивать компоненты по двум параметрам:

• Тональность
• Темп

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

Disclaimer: Я не имею никакого отношения к JetBrains, не получаю денег от продвижения Kotlin или от написания данной статьи. Весь материал — это лишь отражение моего личного опыта.

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

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

В этой публикации я собираюсь объяснить свою позицию, а заодно опишу некоторые особенности перехода с Java на Kotlin как в условиях стартапа, так и в условиях крупного энтерпрайз-проекта.

Всем привет, меня зовут Олег, я техлид в ДомКлике. В нашей команде ядром стека является Kotlin и Spring Boot. Хочу поделиться с вами своим опытом по взаимодействию и особенностях работы с PostgreSQL и Hibernate в связке со Spring Boot и Kotlin. Также на примере микросервиса, покажу преимущества Kotlin и его отличия от аналогичного приложения на Java. Расскажу о не совсем очевидных сложностях, с которыми могут столкнуться новички при использовании этого стека с Hibernate. Статья будет полезна разработчикам, желающим перейти на Kotlin и знакомых со Spring Boot, Hibernate Java.

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

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

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

В качестве задачи можно взять относительно популярную вещь — мы сделаем некоторое подобие AOP для разбора ответов от базы данных. Таким образом, программист сможет разметить атрибутами свой код, а мы сгенерим и скомпилируем рабочий оптимизированный код сразу в runtime. Однако на самом деле, область применения подобной тактики намного шире: можно делать программируемую конфигурацию, можно оптимизировать существующий код (за счет замены условий на заранее подсчитанные значения, которые уже не изменятся). Ну и, конечно же, можно избежать копипаста даже в тех случаях, когда выразительности языка недостаточно, чтобы выделить обобщенный кусок кода.

Весь код доступен на GitHub, для запуска необходима Java 11. В статье я привожу сокращенные варианты кода, без логов, диагностики и т.д.

Примерно 1-1,5 года назад Spring Webflux был на хайпе. Практически на любой Java-конференции можно было встретить доклады по Webflux, реактивному программированию, где-то даже проскакивали доклады про RSocket. Выступлений было много, сообщество маленькое, работающих проектов еще меньше. Возможно, тому виной была достаточно сырая технология в мире Spring и отсутствие поддержки со стороны многих модулей экосистемы, но мы рискнули.

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

Как с помощью smart-contract мы построили систему отбора лучших технологических проектов в ИТ МТС? И в какие «ловушки» мы попали, но смогли выбраться, доказав в итоге, что вести распределенный реестр на мобильных устройствах возможно!

Для чего понадобилась система на основе blockchain?

Начнем с самого начала. В МТС есть давняя традиция – выбирать лучший технологический проект, сделанный за год, и награждать его команду. Команда получает призы, уважение и славу. За долгие годы победителями становились различные проекты: от высоконагруженных телеком-систем до систем искусственного интеллекта.

Выборы лучшего проекта всегда происходили в несколько этапов:

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

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


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

С одной стороны — мне досадно. Я понимаю, что их задавали все остальные — но я же не задавал. Я, наверное, последний чисто гуманитарный журналист в России, которому хочется рассказывать людям об инженерной стороне индустрии, а не только о поднятых миллионах успешных бизнесменов; и который не будет задавать вот это жалкое “ну объясни моим слушателям на пальцах, как это работает, чтобы они поняли”.

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

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

Когда Дудь выпустил ролик про долину, я очень сильно расстроился. Я ещё не знал, про что он конкретно, но мозг моментально нарисовал: манерные успешные успехи говорят про преодолевание, дух предпринимательства, поднятые миллионы баксов, и как сильно их говноприложенька влияет на мир.

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

Мои новостные ленты были завалены обсуждениями, восхищением и критикой выпуска. Каждый раз читая что-то об этом, я испытывал непонятную почти физическую боль. Ну хорошо, главный журналист страны рассказал про мою индустрию, но рассказал не так, как хочу я. С этим можно жить. Да, со всей своей преисполненностью и трушной технарскостью, я все ещё маленький завистливый чмошник. Я тоже хочу сидеть в кофейне в Пало-Альто и смотреть, как мне выписывают чек на пять миллионов долларов. Но смотрите, я вырос в России и давно научился не обращать внимания на свою патологическую зависть. Мне давно не бывает от нее больно.

Бомбанул я точно не от зависти — и я долго не знал, почему.

Несколько дней назад Ron Pressler разродился статьей State of Loom, которую не полайкал только самый ленивый джавист. Статья действительно хорошая, в ней много интересных метафор, которые я собираюсь бессовестно использовать теперь без ссылки на первоисточник.

Со своей стороны я неосторожно позволил высказать некоторый скептицизм, когда же с этим Project Loom можно будет наконец-то реально поработать. Спустя буквально час прилетела ответочка от самого Ron'а — «а ты попробуй!». Что ж, пришлось пробовать.

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

Спустя несколько месяцев, когда я достаточно подумал, попрокрастинировал и поработал, у меня уже получилось решение, более подходящее именно для Android, так как основано на LiveData. Прошу всех интересующихся ознакомиться.

Меня зовут Александр Коцюруба, я руковожу разработкой внутренних сервисов в компании ДомКлик. Многим разработчикам, пишущим на Java, с опытом приходит понимание внутреннего устройства JVM. Чтобы облегчить этот путь Java-самурая, я решил простым языком изложить основы виртуальной машины Java (JVM) и работы с байткодом.

Что такое таинственный байткод и где он обитает?

Постараюсь ответить на этот вопрос на примере приготовления солений.