По поводу Android PC:

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

Уже в Android 16 QPR2 появится Linux Terminal с возможностью запускать десктопные приложения. Т.е. в теории можно будет запустить Android Studio прямо на устройстве, разрабатывать и тестировать приложения прямо на нем же.

Но на самом деле сделать это можно уже сейчас — один реддитор поделился тем, как запускает Android Studio на своем смартфоне через Termux с x11, чтобы изучать программирование во время работы. Что интересно, проект у него на смартфоне компилируется даже быстрее, чем на ноутбуке:)

И кажется, что тут начинает наконец появляться ценность в планшетах на Android. Тот же iPad позиционируется, как портативный Macbook (для меня недавно стало открытием, что iPad уже несколько лет работают на тех же Apple Silicon чипах, что и макбуки) — но не для разработчиков, т.к. даже XCode на айпаде сейчас нельзя запустить. Если на Android планшете можно будет запустить любую десктопную программу, и даже заниматься разработкой, то это прям круто.

Один из моих любимых AI-инструментов для разработки: Supermaven. Это просто плагин для автоподстановки кода. Фишка в том, что он:

0) Бесплатный
1) Очень быстрый и точный (учитывает контекст проекта)
2) Работает в России без vpn

Буквально, начинаешь только писать имя функции, а Supermaven уже предлагает подставить готовую имплементацию. Получается намного быстрее, чем попросить написать агента, и, тем более, чем писать самому.

Вот только нюанс — год назад Copilot купил Supermaven, и теперь поддержка плагина практически прекратилась, последнюю версию IDEA он не поддерживает. Но, к счастью, как подсказывают хорошие люди с Реддита, можно чуть подправить манифест плагина, и он заработает.

Наконец настал момент, когда приложения под iOS можно писать на Kotlin, а приложения под Android – на Swift

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

Вот, например, формат TOON — аналог JSON, оптимизированный для экономии токенов при работе с LLM. Убирает лишние скобки, кавычки — словом, все то, что делает JSON читаемым для человека, но слишком тяжелым для ИИ.

// JSON
{
  "users": [
    { "id": 1, "name": "Alice", "role": "admin" },
    { "id": 2, "name": "Bob", "role": "user" }
  ]
}

// TOON 
users[2]{id,name,role}:
  1,Alice,admin
  2,Bob,user

Если смотреть чуть дальше, то получается, что если раньше технологии разработки выбирались по принципу "Есть ли на рынке люди, которые с этим работают?", то скоро, видимо, будет: "Достаточно ли знаком и эффективен с этим языком ИИ?". Ну или уже так.

Это было потно. Едем на финал?

У Claude Code теперь есть web-версия, которая подключается к GitHub и работает в облаке. Всем раздали бесплатных кредитов до 18 ноября (250$ для Pro и 1000$ для Max).

Ну что ж...

> Build me a billion dollar SaaS startup. Don't make mistakes.

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

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

...

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

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

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

Роберт Мартин, "Чистый Код", 2008

tldr:

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

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

Rust devs doing their thing

Как создавали Android View

Chet Haase, один из разработчиков первой версии Android, делится байками о команде в своей книге "Androids: The Team that Built the Android OS".

Тогда Google понятия не имели о том, как нужно разрабатывать операционные системы, поэтому собрали команду из инженеров Oracle, Microsoft, T-Mobile и т.д. У каждого, конечно, было свое мнение и видение прекрасного.

Примечательна глава о разработке системы Android View. В команде шли жаркие споры, на каком языке писать ui — Javascript или Java? Дискуссия закончилась тем, что один из инженеров, Joe Onorato, сел и за сутки написал View.java. Тот самый кирпичик в 20к строк, на котором держится весь Android UI Framework. Вот так и принимаются судьбоносные решения:

“It was basically a furious ‘Let’s get something done’ time. Took about a day, 24-hour marathon. I had Views [UI elements] up on screen.”

Mathias Agopian said of Joe, “He didn’t tell anybody. One morning he showed up and said, ‘Problem solved, it’s in Java. Now we don’t have to talk about it anymore because it’s there.’”

Самое интересное, на мой взгляд, изменение в Compose 1.10: появилось новое API для сохранения состояния — retain {}. Это аналог rememberSaveable (т.е. сохраненный объект переживает смену конфигурации), но без сериализации (т.е. смерть процесса он не переживет).

Мне кажется, в Android Developers Blog немного неудачно позиционируют это API. Да, сохранять инстанс ExoPlayer при смене конфигурации это, конечно, здорово. Но по сути ведь retain — это аналог ViewModel, который можно привязать к любой Composable функции. То есть, для привязки не нужен ни Activity, ни Fragment, ни NavEntry. Просто функция.

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

Вот несколько примеров, что возможно с retain:

— Stateful UI-компоненты. Кнопка с несколькими состояниями и сложной логикой — в собственной вьюмодели.

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

— Разные инстансы вьюмодели одного типа для элементов ViewPager.

Примеры взяты из описания опенсорсной библиотеки resaca, которая существует уже некоторое время и дает похожий на retain {} API. Но оффициальную библиотеку ведь использовать всегда приятнее.

Для чего нужны inline функции в Kotlin?

Часто этот вопрос задают на собеседованиях. И самый популярный ответ звучит примерно так: Inline функции нужны для оптимизации. С inline лямбда-аргументы функций не оборачиваются в объект, а просто вставляются в место вызова.

В целом это верно. Но такой ответ не учитывает, что JIT-компилятор JVM сам умеет инлайнить функции, если это улучшает перформанс. Мы, как разработчики, не должны (в общем случае) заниматься микрооптимизациями, которые и так делает компилятор или виртуальная машина.

А вот для чего на самом деле нужен inline:

1. Работа с generic типами. В java/kotlin действует type erasure. При компиляции вся информация о generic типах стирается. Если все же нужна информация о типе generic в рантайме, то используется inline + reified.

inline fun <reified R> List<*>.filterIsInstance(): List<R> {
    val destination = ArrayList<R>()
    for (element in this) {
        if (element is R) destination.add(element)
    }
    return destination
}

2. Non-local returns.
Inline позволяет делать возврат из вышестоящей функции прямо внутри лямбды:

fun hasZeros(ints: List<Int>): Boolean {
    ints.forEach {
        if (it == 0) return true // returns from hasZeros
    }
    return false
}

3. Сохранение контекста.
Это фича, без которой работа с Compose и Coroutines не была бы такой приятной. Лямбда внутри Inline-функции наследует весь контекст места вызова (окрашивается в тот же цвет). Например, функция List.forEach принимает обычную лямбду (не Composable), но внутри нее все равно можно вызывать Composable функции — как раз благодаря тому, что forEach — это inline функция.

@Composable
fun Items(items: List<String>) {
    Column {
        items.forEach {
            Text(it)
        }
    }
}

Чем заманивали бигтехи раньше: "Офис у метро, печеньки на кофепоинте"

Чем заманивают сейчас:

А, так вот оно зачем

Кроссплатформа против ИИ

Все, наверное, слышали, как в OpenAI навайбкодили Android приложение Sora с нуля до прода всего за 28 дней. Оригинал статьи тут.

Несколько заметок:

1. Над проектом работали 4 Senior Android разработчика. Вначале они руками написали несколько показательных фичей, засетапили инфраструктуру и кучу инструкций AGENTS.md, только после этого код начал писать ИИ агент.

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

3. По сути команда копировала iOS приложение, которое уже было выпущено на тот момент. И вот это интересно в контесте размышлений о том, насколько разработка с ИИ может убить кроссплатформу. Агенту дали доступ к репозиториям ios и бэкенда, чтобы он копировал бизнес-логику и требования оттуда. Как говорят, вышло неплохо:

We started our project with a huge stepping stone: Sora had already shipped on iOS. We frequently pointed Codex at the iOS and backend codebases to help it understand key requirements and constraints. Throughout the project we joked that we had reinvented the idea of a cross‑platform framework. Forget React Native or Flutter; the future of cross‑platform is just Codex.

Я не считаю, что это прямая замена кроссплатформы. У React Native и Flutter другой кейс применения — удешевить разработку нового приложения под несколько платформ одновременно, а не портировать одно нативное приложение на другую платформу.

А вот с применением KMP (изначальный смысл которого в том, чтобы портировать код с Android приложения в iOS) подход из статьи сильно пересекается. Впрочем, KMP, кажется, был dead on arrival (как и Swift for Android) еще до бума ИИ агентов. Уже давно нет такого количества новых мобильных проектов, чтобы тратить ресурсы на обучение/найм людей под еще одну кроссплатформу, а в существующие проекты KMP тоже затаскивать дорого и не всегда понятно, стоит ли оно того.

А вот и первые подарки

С наступающим!

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

Так вот, эта точка зрения разбивается об очевидную истину:

Работа, которую сегодня вы делегируете ИИ, является работой, которую завтра ИИ у вас отнимет.

Значит, чтобы получить преимущество, нужно как раз вдвойне сосредоточиться на том, что ИИ делать не умеет (и вряд ли научится до появления AGI).

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

Словом, ИИ может быть неплохим кодером, но ему не стать инженером.

Выходит, глобально ничего не изменилось. По-прежнему нужно учить базу computer science. Повышать уровень экспертизы в своей и смежных специальностях. Улучшать софт-скиллы. Заглядывать "под капот" технологий. Стремиться быть незаменимым.

График количества вопросов в месяц на StackOverflow (источник)

Кто знает, что случилось?)