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

В целом, информационное пространство мобильной разработки довольно обособлено. Не выходя из него намеренно, мы редко узнаём про новости из мира backend, web-frontend или ML. При этом со временем тренды приходят из одной области в другую. Как пример — мода на реактивное программирование, завезенная из мира Java и бэкенда, которая постепенно сменяется асинхронным программированием благодаря языку Kotlin, который теперь активно захватывает свою долю в мире бэкенда. Или UDF-архитектуры, которые перетекли к нам из фронтенда, сменив MVP-архитектуру, когда-то перенесённой из бэкенда.

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

Эта публикация — перевод поста Романа Елизарова «Shared flows, broadcast channels». Опубликовано с одобрения автора оригинала. Примечания переводчика выделены курсивом.

Давным-давно в Kotlin были представлены корутины, одной из особенностей которых является легковесность (создание корутин дешевле, чем с запуск новых Threads). Мы можем запускать несколько корутин, и нам нужен способ взаимодействия между ними избегая “mutable shared state”

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

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

Этот пост не является техническим, если Вы хотите посвятить время исключительно техническим статьям, не читайте его.

Также здесь не будет поднадоевшего уху слова на букву «к».

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

Однажды мне понадобилось сканировать из Android приложения сети Wi-Fi и получать подробную выкладку данных о точках доступа.

Блокчейн-протоколы должны обеспечивать консенсус среди нод децентрализованной системы. Пожалуй, самым известным алгоритмом консенсуса можно считать «тормозунутый, но надежный, потому что тормознутый» алгоритм Proof-of-Work: каждая нода, имея набор новых транзакций перебирает некоторое число nonce, являющееся полем блока. Блок считается валидным, если валидны все транзакции внутри него и хэш-функция от заголовка блока имеет некоторую общепринятую особенность (например, количество нулей в начале, как в Bitcoin):

Hash(  Block{transaction,nonce,…} ) = 000001001...

Как известно, блокчейн — это цепочка блоков. Цепочкой он является потому, что внутри каждого блока записан id (как правило хэш от заголовка) предыдущего блока. Для последующих рассуждений блокчейн в упрощенном виде можно представить так:

Эта статья в первую очередь пригодится тем, кто пишет ТЗ для программистов, и программистам, которые решили разрабатывать прототип самостоятельно.

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