Kotlin *

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Около года назад я заинтересовался новой технологией Kotlin Multiplatform. Она позволяет писать общий код и компилировать его под разные платформы, имея при этом доступ к их API. С тех пор я активно экспериментирую в этой области и продвигаю этот инструмент в нашей компании. Одним из результатов, например, является наша библиотека Reaktive — Reactive Extensions для Kotlin Multiplatform.

В приложениях Badoo и Bumble для разработки под Android мы используем архитектурный шаблон MVI (подробнее о нашей архитектуре читайте в статье Zsolt Kocsi: «Современная MVI-архитектура на базе Kotlin»). Работая над различными проектами, я стал большим поклонником этого подхода. Конечно, я не мог упустить возможность попробовать MVI и в Kotlin Multiplatform. Тем более случай был подходящий: нам нужно было написать примеры для библиотеки Reaktive. После этих моих экспериментов я был вдохновлён MVI ещё больше.

Я всегда обращаю внимание на то, как разработчики используют Kotlin Multiplatform и как они выстраивают архитектуру подобных проектов. По моим наблюдениям, среднестатистический разработчик Kotlin Multiplatform — это на самом деле Android-разработчик, который в своей работе использует шаблон MVVM просто потому, что так привык. Некоторые дополнительно применяют «чистую архитектуру». Однако, на мой взгляд, для Kotlin Multiplatform лучше всего подходит именно MVI, а «чистая архитектура» является ненужным усложнением.

Поэтому я решил написать эту серию из трёх статей на следующие темы:

1. Краткое описание шаблона MVI, постановка задачи и создание общего модуля с использованием Kotlin Multiplatform.
2. Интеграция общего модуля в iOS- и Android-приложения.
3. Модульное и интеграционное тестирование.

Ниже — первая статья серии. Она будет интересна всем, кто уже использует или только планирует использовать Kotlin Multiplatform.

Продолжаем нашу подборку интересных материалов (первая часть, вторая часть, третья часть). На этот раз много материалов про Kotlin, а также анонс нового эфира ток-шоу для айтишников «Oh, my code» с Павлом Dzirtik Щербининым, который состоится сегодня вечером.

Всем привет.

Несколько дней назад JetBrains выпустил новую версию корутин — 1.3.6 и одним из нововведении стал новый подвид Flow — StateFlow, который приходит на замену ConflatedBroadcastChannel. Я решил попробовать StateFlow в действии и изучить внутреннее устройство.

Цель статьи заключается в том, чтобы показать какие возникают трудности при использовании Spock с Kotlin, какие есть пути их разрешения и ответить на вопрос, стоит ли использовать Spock, если вы разрабатываете на Kotlin. Подробности под катом.

Зачем статья

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

Что такое GraphQL

GraphQL — модная альтернатива REST API, которая позволяет запрашивать данные более оптимизированным способом, отдавая только нужные вам данные.

Настройка окружения

Делать запросы к серверу мы будем через Apollo — самая популярная библиотека для работы с GraphQL на данный момент.

Приступим к работе. Первым делом давайте добавим в манифест нужные разрешения для работы с сетью:

<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />

Далее необходимо подключить apollo. Идём в основной build.gradle и в разделе dependencies добавляем следующую строчку:

classpath 'com.apollographql.apollo:apollo-gradle-plugin:2.0.0'

Теперь необходимо в файле build.gradle модуля app подключить дополнительные зависимости:

implementation("com.apollographql.apollo:apollo-runtime:2.0.0")
implementation "com.apollographql.apollo:apollo-android-support:2.0.0"

Кроме того, в самый верх файла добавим подключение плагина:

apply plugin: 'com.apollographql.apollo'

После того, как проект синхронизировался, нам нужно настроить кодогенерацию моделей, с помощью которых мы будем делать запросы к GraphQL.

Свернем среду разработки и откроем терминал. Переходим в папку с вашим проектом:

Эй, как насчет интерактивной командной оболочки с автодополнением, помощью и прочим? И без заморочек да еще и на JVM?

Головной болью на работе для меня стал Postman. Хотя на словах мы все TDD и по красному огоньку Cucumber видим, что именно сломалось, но на практике приходилось мне гораздо чаще слать REST запросы в интерфейсе Postman. При начале работы надо было получить токен аутентификации (запрос на создание и запрос на валидацию, пользователи разные), а потом скакать по закладкам, править параметры и запускать уже другие запросы. Клик-клик-клик. В разном порядке. Уж я и скрипты с cURL писал, и в IDEA запросы оформлял — не удобно. Идеальный мотиватор для перехода на автоматические тесты, вот только это были запросы на получение понимания, что происходит в какой-то уникальный момент сочетания состояния сервиса, его версии, мейнфреймов за ним, погоды в доме и уж точно под регрессионное тестирование не попадали. Клик-клик-клик стал съедать слишком много времени и накручивал километраж мышки.

И тут на глаза мне попался проект Spring Shell, который запускает свой shell в консоли и выполняет команды, написанные в терминах Spring. Давно оценив преимущества командной строки, я сразу взялся за решение своей проблемы. Сказать, что результатом я остался доволен — это преуменьшение. Под катом — абстрактный проект для демонстрации возможностей shell, который навеян моим опытом. Чтобы сделать совсем красиво, я добавил плюшек с еще одним малоизвестным проектом — Spring State Machine. Может показаться, что конечные автоматы — это для седых профессоров, но реальность такова — на них, например, написаны корутины в Kotlin, а всякие Akka их несут в "массы" еще дольше. Я коснусь State Machine совсем поверхностно, только чтобы разогреть аппетит.

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

В 2017 году увидел свет амбициозный проект от компании Jetbrains, предлагающий новый взгляд на кросс-платформенную разработку. Компиляция кода на kotlin в нативный код различных платформ! Мы же в Домклике в свою очередь всегда ищем способы для оптимизации процесса разработки. Что может быть лучше переиспользования кода, подумали мы? Правильно — не писать код вообще. И чтобы всё работало так, как хочется. Но пока так не бывает. И если есть решение, которое позволило бы нам, не затрачивая слишком больших усилий, использовать единую кодовую базу для разных платформ, почему бы не попробовать?

Итак, всем привет! Меня зовут Геннадий Васильков, я андроид разработчик в компании Домклик и сегодня я хочу поделиться с вами нашим опытом разработки на Kotlin Multiplatform для мобильных устройств, рассказать с какими трудностями мы столкнулись, как решали и к чему в итоге пришли. Тема наверняка будет интересна тем, кто хочет попробовать Kotlin MPP (Multiplatform projects), либо уже попробовал, но не довёл до продакшена. Либо довёл, но не так как хотелось бы. Я попробую донести наше видение того, как должен быть устроен процесс разработки и доставки разработанных библиотек (на примере одной из них расскажу начало нашего пути становления в Kotlin MPP).

Желаете историй как у нас всё получилось? Их есть у нас!

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

Хотя есть и другой вариант. Не надо ничего пока менять и/или на что-то влиять. Пусть будет многопоточность и корутины, пусть будет… и параллельное автоматное программирование (АП). Пусть соревнуются и, когда это необходимо и возможно, дополняют друг друга. В этом смысле у современного параллелизма есть, как минимум, один плюс — он позволяет это делать.

Ну, так что, посоревнуемся!?

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

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

Меня зовут Александр Коцюруба, руковожу разработкой внутренних сервисов в компании ДомКлик. Отвечая на вопрос, почему мы перешли на Kotlin, я опубликую два материала:

1. Первая часть будет посвящена ретроспективе возникновения языка (которую вы, собственно, и будете сейчас читать)
2. Вторая часть будет ориентирована на практически примеры (которая выйдет позже)

Итак, начнем.

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

В прошлом году наши эксперты, занимающиеся автотестами под Android, объединились с коллегами из других компаний и создали фреймворк для автотестирования Kaspresso. В сентябре они представили его на «Хабре» (пост, в котором они объясняют, что сделали и зачем). За полгода существования Kaspresso воспользовались тысячи людей, и у многих возникали те или иные вопросы про фреймворк и инфраструктуру в целом. Мы заметили, что часто эти вопросы повторяются, и подумали, что на них хорошо бы ответить централизовано.

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

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

Реализовать сжатие RLE (run-length encoding). Продумать алгоритм сжатия и формат файла, при котором сжатие «неудачных» данных не приводит к большому увеличению размера файла.

Command Line: pack-rle [-z|-u] [-out outputname.txt] inputname.txt

Упаковывает -z или распаковывает -u указанный в аргументе командной строки текстовый файл. Выходной файл указывается как -out outputname.txt, по умолчанию имя формируется из входного файла с добавлением расширения.

Кроме самой программы, следует написать автоматические тесты к ней.

Сам алгоритм:

Кодирование длин серий (англ. run-length encoding, RLE) или кодирование повторов — алгоритм сжатия данных, заменяющий повторяющиеся символы (серии) на один символ и число его повторов. Серией называется последовательность, состоящая из нескольких одинаковых символов. При кодировании (упаковке, сжатии) строка одинаковых символов, составляющих серию, заменяется строкой, содержащей сам повторяющийся символ и количество его повторов.

Строка: WWWWWWWWWBBBWWWWWWWWWWWWWWWWWWWWWWWBWWWW
Превращается в строку: 9W3B24W1B4W
Однако я чуть улучшил алгоритм, убрав добавление 1 перед одиночным символом, чтобы избежать ситуации, когда сжатая строка длиннее исходной. («TBTB» -> «1T1B1T1B» «TBTB»)

/ Оригинал /

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

Под катом история про то, как мы испытывали Kotlin на гибкость (и пару раз сломали), реализуя MVP-библиотеку Summer без кодогенерации и с поддержкой Kotlin Multiplatform.