Kotlin *

Введение

При Андроид разработке мы используем разные архитектурные решения(паттерны). Например Mvp, Mvvm, Mvi и т.д… Каждый из этих паттернов решает несколько важных задач и поскольку они не идеальны они нам оставляют кое-какие нерешенные задачи. К примеру этих задач относятся навигация внутри приложения(routing), передача информации с экрана на экран(говоря экран я имею ввиду Activity, Fragment или View), Сохранение состояний приложения при смене конфигурации(configuration change).

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

Существует множество способов обработки сообщений из Pub-Sub систем: использование отдельного сервиса, выделение изолированного процесса, оркестрация пулом процессов/потоков, сложные IPC, Poll-over-Http и многие другие. Сегодня я хочу рассказать о том, как использовать Pub-Sub по HTTP и про свой сервис, написанный специально для этого.

Использование готового HTTP -бэкенда сервисов в некоторых случаях является идеальным решением для обработки очереди сообщений:

1. Балансировка из коробки. Обычно, бэкенд и так стоит за балансировщиком и имеет готовую к нагрузкам инфраструктуру, что сильно упрощает работу с сообщениями.
2. Использование обычного REST-контроллера (любой HTTP-ресурс). Потребление сообщений по HTTP сводит к минимуму затраты на реализацию консюмеров под разные языки, если бэкенд разношерстный.
3. Упрощение использования Веб-хуков других сервисов. Сейчас почти каждый сервис (Jira, Gitlab, Mattermost, Slack…) так или иначе поддерживает Веб-хуки для взаимодействия с внешним миром. Можно облегчить жизнь, если научить очередь выполнять функции HTTP-диспатчера.

Этот подход имеет и минусы:

1. Можно забыть о легковесности решения. HTTP тяжёлый протокол, а использование фреймворков на стороне консюмера мгновенно приведёт к увеличению задержки (latency) и нагрузки.
2. Лишаемся сильных сторон Poll-подхода, получая слабые стороны Push.
3. Обработка сообщений теми же инстансами сервиса, которые обрабатывают клиентов, может сказаться на отзывчивости. Это несущественно, так как лечится балансировкой и изоляцией.

Я реализовал идею в виде сервиса Queue-Over-Http, о котором и пойдёт речь далее. Проект написан на Kotlin с использованием Spring Boot 2.1. В качестве брокера сейчас доступна только Apache Kafka.

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

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

После подобного всерьез задумываешься о обработке ошибок — и какие же возможности предоставляет нам Kotlin?

Первым на ум приходит try-catch. По мне — отличный вариант, но у него есть две проблемы:

1. Это как-никак лишний код (вынужденная обертка вокруг кода, не лучшим образом сказывается на читаемости).
2. Не всегда (особенно при использовании сторонних библиотек) из блока catch возможно получить информативное сообщение о том, что конкретно вызвало ошибку.

Давайте посмотрим во что try-catch превращает код при попытке решения вышеозвученных проблем.

Когда вы пишите command line утилиту, последнее, на что вам хочется полагаться, так это на то, что на компьютере где она будет запущена установлен JVM, Ruby или Python. Так же хотелось бы на выходе иметь один бинарный файл, который будет легко запустить. И не возиться слишком много с memory management'ом.

По вышеозначенным причинам, в последние годы всегда, когда мне нужно было писать подобные утилиты, я использовал Go.

У Go относительно простой синтаксис, неплохая стандартная библиотека, есть garbage collection, и на выходе мы получаем один бинарник. Казалось бы, что еще нужно?

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

В этой статье я расскажу об основах внедрения зависимостей (англ. Dependency Injection, DI) простым языком, а также расскажу о причинах использования этого подхода. Эта статья предназначена для тех, кто не знает, что такое внедрение зависимостей, или сомневается в необходимости использования этого приёма. Итак, начнём.

Сообщество «Google Developers Group» в Петербурге основано в 2006 году. Однако подвести итоги года мы решили впервые. GDG проводит IT конференции и митапы для разработчиков Android, Kotlin, Scala, Firebase, Dart и Assistant. В 2018 году мы провели 17 конференций и митапов. Под катом вы найдете итоги и отзывы о мероприятиях, а ещё все материалы и записи классных докладов!

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

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

Решил написать о некоторых вещах, которых, по моему мнению, стоит и не стоит избегать при использовании корутин Kotlin.

6 декабря мы провели очередной Java-митап. Там говорили вот о чём:

• о разработке Moira — системы экстренного реагирования на инциденты (про ракеты — здесь);
• о контрактах в Kotlin, задачах, проблемах и улучшениях для DSL;
• о том, как роботом выбирать ревьюеров в большой команде разработчиков;
• о том, как научить все компоненты генерировать графики и метрики на боевой среде;
• о правильной обратной связи для обнаружения проблемных релизов.

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

Мы уже выложили на YouTube видеозаписи докладов JPoint 2018 и специально для хаба Java на Хабре сделали традиционную подборку самых лучших из них по мнению посетителей конференции.

Как обычно, наверху «младшие» доклады, в конце — с самым высоким рейтингом. Конечно, это не значит, что один доклад намного хуже другого: если изменить методику расчета, места могут легко поменяться. В реальности, мы её и изменили, теперь используется «soft quorum» вариант рейтинга, учитывающий количество присутствовавших на докладе участников. Этот подход имеет свои минусы (например, на кейноут приходит больше людей, чем на обычный доклад, просто потому что у аудитории нет выбора), но в целом даёт более качественную картину произошедшего.

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

Автор: Сергей Ешин, Strong Middle Android Developer, DataArt

Уже более полутора лет прошло с тех пор, как Google объявил об официальной поддержке Kotlin в Android, а самые матерые разработчики начали экспериментировать с ним в своих боевых и не очень проектах больше трех лет назад.

Новый язык тепло приняли в Android-сообществе, и подавляющая часть новых проектов на Android стартует с Kotlin на борту. Важно и то, что Kotlin компилируется в JVM-байткод, следовательно, полностью совместим с Java. Значит, в существующих Android-проектах, написанных на Java, тоже есть возможность (более того — потребность) задействовать все фичи Kotlin, благодаря которым он и приобрел столько поклонников.

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

Насколько быстро парсится Kotlin и какое это имеет значение? JavaCC или ANTLR? Годятся ли исходники от JetBrains?

Сравниваем, фантазируем и удивляемся.

Привет, Хабр! Представляю вашему вниманию перевод статьи "Modern Android development with Kotlin (Part 2)" автора Mladen Rakonjac.

Примечание. Данная статья является переводом циклов статей от Mladen Rakonjac, дата статьи: 23.09.2017. GitHub. Начав читать первую часть от SemperPeritus обнаружил, что остальные части почему-то не были переведены. Поэтому и предлагаю вашему вниманию вторую часть. Статья получилась объёмной.



«Очень сложно найти один проект, который охватывал бы всё новое в разработке под Android в Android Studio 3.0, поэтому я решил написать его.»

18 декабря приглашаем на первый открытый митап Camunda BPM, который пройдет на площадке Райффайзенбанка в Нагатино.

Для нас очень важно формировать сообщества и делиться знаниями и опытом как внутри компании, так и во вне. Именно поэтому на регулярной основе мы проводим открытые митапы по разным направлениям. В этот раз мы открываем двери и приглашаем вас на первый митап Camunda BPM. В рамках митапа мы также хотим создать и чат Camunda BPM User Group, с чатом жить гораздо проще, ведь тогда появляется возможность что-то быстро спросить у коллег или просто скинуть интересную статью или мем. Хотите в чат? Тогда вам сюда

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



Сегодня названием Kotlin уже сложно кого-то удивить, особенно в Android-разработке. То ли дело в начале 2016-го: востребованность была на порядок ниже, об официальной поддержке Google ещё и речи не шло, и писать на Kotlin было уделом смелых духом. Одним из таких смельчаков стал Антон Кекс, и впоследствии он тоже уделял Kotlin много внимания (например, дважды выступал на KotlinConf). Поэтому мы решили расспросить его о том, как жизнь Kotlin-разработчика менялась со временем.

А чтобы два раза не вставать, охватили и другую тему. Антон — сооснователь эстонской компании Codeborne, практикующей extreme programming, поэтому заодно узнали, что в Эстонии с IT и каково создавать там собственную компанию.

В течение лета 2018 года было разработано и обновлено множество отличных Android-библиотек и инструментов.

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

Надеюсь, вам понравится. Давайте начнём!

В процессе разработки CUBA мы применяли все три основных инструмента сборки — начали с Ant, потом перешли на Maven на короткое время, а сейчас используем Gradle и, похоже, что в ближайшее время останемся с ним.

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

Привет, Хабр! Предлагаю вашему вниманию авторский перевод страницы документации Kotlin Coding Conventions от JetBrains.

→ Оригинал документации

Мир сходит с ума. Говорят, все новые мобильные проекты на Андроиде пишут исключительно на Котлине. В наше время очень опасно не учиться новым технологиям. Вначале твои знания устаревают, ты вылетаешь с работы, живешь у теплотрассы, дерёшься с бомжами за еду и умираешь в безвестности, так и не выучив функционального программирования. Поэтому я отправился на Курсеру изучать курс Kotlin for Java Developers и начал читать книжку (привет, abreslav, yole), поспрашивал друзей сами знаете откуда и вернулся назад с некой пустотой в душе. Помогите Олегу-путешественнику найти смысл в Котлине!

• Бонус: хаброопрос «Как вы используете Kotlin?»

Нельзя просто взять и распечатать страницу написанную на React: есть разделители страниц, поля для ввода. Кроме того, хочется один раз написать рендеринг, чтобы он генерил как ReactDom, так и обычный HTML, который можно сконвертить в PDF.

Самое сложное, что у React свой dsl, а у html свой. Как решить эту проблему? Написать ещё один!

Чуть не забыл, всё это будет написано на Kotlin, так что, на самом деле, это статья о Kotlin dsl.