Я постарался придумать самое простое объяснение дизайн-токенов на примере житейских ситуаций. Что это такое, как работают и зачем они нужны — в этой статье.

Про принципы наименований, экспорт токенов из фигмы и передачу токенов разработчикам.

Если конкретнее, то функционально полно вычитание с плавающей точкой по IEEE-754 . Это значит, что можно создать любую двоичную схему на одном только вычитании с плавающей запятой.

Чтобы понять, как это сделать, нужно начать снизу. Цитата из раздела 6.3 стандарта IEEE 754-2019:

Привет, дорогие читатели! В предыдущей моей статье "Как легко перейти с Java на Rust" я делился с вами советами по переходу на Rust и уменьшению количества "потерянной крови" на этом пути. Но что делать дальше, когда вы уже перешли на Rust, и ваш код хотя бы компилируется и работает? Сегодня я хочу поделиться с вами некоторыми идеями о том, как писать идиоматический код на Rust, особенно если вы привыкли к другим языкам программирования.

Пакеты в Java появились с самого начала, во времена, когда язык еще назывался Oak. Их описание уже присутствует в его ранних спецификациях.

Java-пакеты реализуют так называемое пространство имен (namespace), позволяющее использовать в проекте файлы с одинаковыми именами. Такой подход существует с давних времен во многих языках.

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

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

Об этом и многом другом и пойдет речь в данной статье.

Всем привет! Меня зовут Нурислам (aka tonitaga), и сегодня я бы вам хотел рассказать об Базовых алгоритмах на графах.

Аргентум - язык программирования, построенный на новой ссылочной модели, которая не использует сборщик мусора и гарантирует отсутствие утечек памяти.

Сроки

В разработке ПО существует неразрешимое противоречие — это оценка сроков.

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

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

• новая функциональность нетипична
• есть зависимости на другие команды
• будет задействована новая технология
• ТЗ надо сильно уточнять
• надо разобраться в логике легаси-кода

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

В мае 2023 года команда ГК Юзтех организовала в Томске Usetech Meetup «Тренды мобильной разработки», где своим опытом поделились эксперты российского ИТ-рынка. По итогам мероприятия мы написали серию статей, каждая из которых посвящена актуальным вопросам и транслирует выступление одного из спикеров. Начнем с выступления Алексея Гладкова, Mobile Developer компании Тинькофф.

Про Kotlin Multiplatform (КММ) многие слышали, но пробовали далеко не все. Мы с командой использовали его в работе, и здесь я расскажу о своем опыте. Возможно, теперь у вас появится понимание, как аргументировать бизнесу зачем вообще нужен KMM и насколько это сейчас рабочая история. 

Для начала пару слов о себе: меня зовут Алексей Гладков, работаю в компании «Тинькофф», преподаю в МФТИ, пишу нативные приложения уже около 10 лет, веду ютуб-канал про мобильную разработку «Mobile Developer».

Доклад, с которым я выступал в рамках митапа, называется «The State of Kotlin Multiplatform», поскольку все время выходят какие-то новые фичи, и я его дополняю. Для меня это, условно, дайджест, который я регулярно обновляю. Сейчас я расскажу о текущем состоянии Kotlin примерно на начало апреля 2023 г. 

Почему вообще надо задумываться о мультиплатформенном подходе? В 2015 году (еще даже не вышли часы Apple Watch) мы, мобильные разработчики, в основном ориентировались на телефоны. Другие разработчики ориентировались на планшеты и ноутбуки. То есть было четкое разделение. К 2023 году ситуация изменилась. Теперь ко мне могут прийти и сказать: «Мы на телевизоре хотим запуститься» или «На часах». Вполне себе реальная история. Дальше эта тенденция будет только развиваться – у нас будут появляться:

В Android разработке может наступить момент, когда для тестирования приложения на различных устройствах может потребоваться виртуальное устройство. Эмулятор Android легко можно создать с помощью GUI Android Studio, но также можно и с помощью командной строки на macOS. В этой статье я расскажу вам, как именно это сделать!

Шаг 1: Установите Java

Убедитесь, что в вашей системе установлена ​​Java. Если нет, то это можно сделать с помощью Homebrew, выполнив следующую команду:

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

Давайте попробуем немного разобраться в теме импульсных нейронных сетей (spiking neural network, SNN). Напишем простую импульсную нейронную сеть, используя только NumPy и Pandas, для классической задачи машинного обучения с использованием кодирования рецептивными полями.

Привет, меня зовут Андрей Богомолов, я Android-разработчик в команде "Платформа" приложения Ozon Seller.

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

Наша команда Ozon Seller также столкнулась с этой проблемой. Мы решили собрать воедино все советы и наработки по написанию оптимизированного Compose-кода. Активное применение этих советов при оптимизации существующих экранов и написании новых существенно улучшило наши метрики: длительность лага по отношению к длительности скролла (hitch rate; чем меньше, тем лучше) экранов со списками упала в среднем с 15-19 % до 5-7 % (на 90-м перцентиле). Все эти советы и наработки мы описали в этой статье. Она будет полезна и начинающим, и опытным разработчикам, в ней подробно описаны оптимизации и механизмы Compose, а также рассказано про слабо задокументированных особенности и исправления ошибок, которые есть в других статьях. Давайте же начнём.

Когда-то в Android были времена, когда запустить задачу в фоне было просто и гарантии ее работы были высоки. Теперь же в ОС есть множество ограничений: работа в фоне, доступ к файловой системе, системы оптимизации расхода батарейки, разрешения, часть которых требует одобрения модераторов Google Play. Разработчикам приходится работать в условиях всех этих ограничений и учитывать их при разработке функций. В рамках этой статьи я хочу разобраться с ограничениями, которые есть на разных версиях Android, чтобы вы смогли лучше понимать, что может происходить.

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

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

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

Когда речь заходит о создании REST-сервера для Kotlin часто на ум приходит фреймворк Ktor (от Jetbrains), использующий важные особенности Kotlin, такие как корутины и DSL-синтаксис. Ktor является модульным решением, для которого созданы расширения для всех наиболее важных аспектов разработки бэкэнда (безопасность, маршрутизация, сериализация данных, применение шаблонов, поддержка сетевых протоколов, управление сессиями, операции с заголовками, извлечение метрик и автоматическая генерация документации по API). Однако это не единственный веб-фреймворк и в некоторых случаях его синтаксис оказывается несколько запутанным (например, операции взаимодействия с неявным объектом call внутри корутин обработки запросов). В этой статье мы рассмотрим альтернативный фреймворк Jooby, который предоставляет схожий с Ktor набор функциональности, но дает больше свободы в выборе механизмов неблокирующей многозадачности и, в ряде случаев, более короткий и явный синтаксис, а также показывает более высокую производительность по результатам тестов.

Привет, Хабр! Я Андрей Мещеряков, Android-разработчик в команде роста Тинькофф Инвестиций. Мы в Инвесте всегда стараемся пробовать новое и поддерживать современный стек технологий. Не обошли стороной и библиотеку Kotlinx.Serialization, которой сейчас пользуемся. Меня удивило малое количество русскоязычных публикаций по Kotlinx.Serialization, и я решил поделиться опытом Инвеста по миграции с Gson на Kotlinx.

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

Всем привет! Я начинающий разработчик и увлекся Embedded стороной вопроса. Лучший способ запомнить информацию - написать какой нибудь конспект и поделиться им. Ниже моя краткая выжимка о CAN шине и передаче данных через нее.

Начнем с простого вопроса:

Что означает QEMU/KVM или QEMU-KVM?

Можно ответить - это QEMU + KVM или qemu-system, запущенный с kvm в качестве ускорителя. Но в какой-то степени это еще и анахронизм, так как с появлением KVM его разработчики для интеграции с QEMU поддерживали отдельный форк qemu-kvm, но начиная с QEMU версии 1.3 (декабрь 2012) все основные изменения из qemu-kvm были перенесены в главную ветку QEMU, а qemu-kvm объявлен устаревшим.

В разных дистрибутивах до сих пор еще можно встретить исполняемый файл qemu-kvm или просто kvm, но это лишь обертки над qemu-system:

exec qemu-system-x86_64 -enable-kvm "$@"

или симлинки:

/usr/bin/kvm -> qemu-system-x86_64

А в самом qemu существует проверка: