Распространение приложений в линуксе - это боль. Причем в наше время цикл обновлений приложений все уменьшается и эта боль чувствуется все сильнее. В связи с этим появляются технологии вроде snap, flatpak, которые декларируют решение этих проблем. Некоторые дистрибутивы (я смотрю на тебя, Ubuntu) даже начинают довольно агрессивную политику по их внедрению. Однако, несмотря на то, что про сами эти технологии много говорят (и ещё больше жалуются), про то, как они работают написано довольно мало. Попробуем исправить это.

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

Для начала разберем небольшую задачу. Она поможет читателю получить представление об основах шифрования.

Представим, что у нас есть сундук с важными документами. Мы хотим отправить его из пункта А в пункт Б, но так, чтобы никто не мог открыть его содержимое по пути следования. На сундук можно повесить замок/замки, отправлять сундук несколько раз, принимать обратно, передавать ключ/ключи через посредника. Посредник может скопировать ключ или даже сам сундук, подобно файлам на компьютере. Как же выстроить цепочку передачи, чтобы посредник не получил доступ к закрытым документам при перевозке?

В сегодняшней реальности практически не бывает IT без интернета. Всё, чем мы пользуемся, ставится и обновляется из интернета, заливается обратно в интернет. А если доступа к интернету вдруг не станет?

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

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

Это такое приятное чувство, когда ты закончил какую-то задачу. А особенно когда твой проект уже готов к релизу. Остался лишь последний шаг.

Публикация проекта в Maven Central, имеено об этом я расскажу в этой статье. Как настроить Gradle, чтобы потом без труда настроить CI.

Привет, Хабр. Хочу поделиться своим решением одной из проблем использования корутин в Kotlin.

Корутины в Kotlin - одна из значимых фич языка, которая позволяет писать асинхронных код в синхронном стиле. Корутины прекрасны во всём, до тех пор пока не возникает необходимость их дебажить.

Сегодня речь пойдет о модном — о RISС-V микроконтроллере. Я давно хотел познакомиться с этим ядром и ждал когда появится что-то похожее на STM32 и вот дождался, встречайте — китайский GigaDevice — GD32V.

Инфраструктура для этого микроконтроллера не такая обширная как для STM32, но есть все необходимое для того, чтобы начать с ним работать. Благо отладочные платы можно заказать на аликекспресс, например, вот тут: Longan Nano GD32VF103CBT6 RISC-V MCU

Китайцы продвигают для этого микроконтроллера среду разработку Platform IO, которую можно поставить как расширение под Visual Studio Code. Но мы не будем её использовать, это ведь не по инженерным понятиям, мы же инженеры и хотим разобраться во всем сами. Поэтому давайте попробуем запустить плату на IAR, написав все с нуля.

Кстати, IAR раздает отладочный комплект (отладочная плата + отладчик I-Jet + 30 Дней полная лицензия) IAR RISC-V GD32V Evaluation kit. Вот тут можно оставить заявку Request for Development Tools. Не уверен, что они посылают комплект всем желающим, но мы получили в течение 5 дней. Спасибо им за это!

Ну что же, кто заинтересовался, добро пожаловать под кат

В предыдущей паре статей я рассуждал про ПЛИС Lattice. Давайте сегодня поговорим об эффективной разработке под них. Один наш крупный руководитель уверяет, что из разговоров с иностранными Заказчиками, он выяснил, что российских разработчиков считают пишущими классные вещи, но делающими это крайне медленно. Ну, разумеется, по сравнению с разработчиками из других стран. И разумеется, «классные» идёт на первом месте.

Один из методов обхода проблемы скорости разработки – использование готовой инфраструктуры для проектов. Я делал цикл статей про комплекс Redd, где продвигал использование готовой шинной инфраструктуры в среде разработки Quartus. Сначала это была честная процессорная система, потом – процессор мы изъяли, а шины – оставили.

Затем я делал пару циклов, где активно использовал данный подход. Мне приходилось дописывать только проблемно-ориентированные модули, остальное — среда разработки создавала за меня.

Есть ли что-то подобное для Lattice в частности и сцепки Yosys/NextPNR в целом? Вы не поверите! Решение не просто есть, но оно ещё и настолько кроссплатформенное, что подойдёт и для Yosys/NextPNR, и для Quartus, и для Vivado! И называется оно Litex. Итак, давайте попробуем поэкспериментировать с ним для подхода, который я уже давно продвигаю: «делаем штатную основу, а на неё нанизываем свои целевые блоки».

Как и большинство UI-фреймворков, Compose рендерит кадр в несколько различных этапов. В системе Android View есть 3 этапа: Measure, Layout и Drawing. Compose очень похож, но имеет важный дополнительный этап Composition в начале.

1. Composition: какой UI показывать. Compose запускает composable-функции и создает описание вашего UI 

2. Layout: где размещать UI. Этот шаг состоит из двух: измерение и размещение (measurement и placement). Элементы верстки измеряют и помещают самих себя и все дочерние элементы в 2D-координатах.

3. Drawing: как рендерить. UI-элементы отрисовываются в Canvas, обычно на экране устройства.

Ноутбук — главный девайс в моей жизни, я провожу за ним бо́льшую часть суток. Он должен быть лёгким, компактным и мощным. Долгое время лидером по этим параметрам был Dell XPS 13, но всё поменялось с выходом MacBook Air на процессоре M1.

Air всего на 100 граммов тяжелее XPS 13, но примерно в три раза мощнее, автономнее и не нуждается в активном охлаждении. Никогда не думал, что скажу подобное про технику Apple, но MacBook Air — самое крутое устройство в своей весовой категории на рынке, оставившее конкурентов далеко позади.

Я фанат Линукса, эта операционная система для меня больше, чем просто окружение. Это философия, новостная повестка и постоянный предмет обсуждения. Поэтому сама идея отказа от Linux в пользу другой ОС меня всегда отталкивала. Да и тот эпизодический опыт, когда приходилось что-то делать в macOS, был эмоционально неприятным.

Но появление M1 посеяло во мне зерно сомнений: мой ноутбук больше не был самым крутым и навязчивой мыслью было то, что я отказываю себе в чём-то большем. Это зерно прорастало и проросло: я купил MacBook Air с 16GB ОЗУ и 512GB SSD, с удивлением обнаружив, что он ещё и стоит дешевле моего XPS. Впереди меня ожидали настройка окружения, борьба с Docker, грусть от отсутствия привычного автодополнения в консоли и много чего ещё.

Одна из проблем статического анализа в том, что его легко сделать умнее, чем надо. В результате он начинает выдавать предупреждения в таком коде, который человеку кажется нормальным. И так и хочется сказать анализатору «Отстань, зануда! Сильно умный что ли?»

Я в очередной раз почувствовал вкус всего этого, когда работал над поиском константных выражений для Kotlin. Ранее такой анализ был для Java, но для Kotlin он впервые появится только в следующей версии IntelliJ IDEA 2021.3. Инспекция базируется на анализе потока данных и находит в коде выражения, которые всегда равны одному и тому же. Изначально такая инспекция на Java сообщала только о логических выражениях, которые всегда равны true или false. Потом мы осторожно расширили её, и она стала сообщать ещё и о выражениях, которые всегда равны null или 0. Было решено проделать тот же путь для Kotlin.

Этот пост будет полезен для Flutter-разработчиков, которым хочется поработать с флейворами (flavours), изменить и дополнить их. Сегодня мы не будем говорить о процессе создания флейворов с разными иконками, названиями и идентификаторами, благо таких публикаций существует уже очень много. Вместо этого речь пойдет о том, как определять флейвор в Dart-коде, а также о решении некоторых часто встречающихся при сборке приложений проблем, связанных с введением флейворов. 

Итак, я рассчитываю, что вы знаете, что такое флейвор и зачем он нужен (если нет, почитайте, например, вот этот материал). Поэтому мы сразу перейдем к тем вопросам, с которыми встречается разработчик Flutter, когда у него возникает задача определить новый флейвор. 

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

Этот текст предназначен для тех, кто только осваивает программирование. Я читаю лекции по C++ на первом курсе местного университета, и в качестве практикума предлагаю запрограммировать любую игру (не выношу проектов типа "софт бронирования книг в местной библиотеке"). Соответственно, чтобы помочь начинающим, я сделал некоторое количество заготовок, с которых можно стартовать свой проект. Например, заготовку олдскульного 3д шутера в 486 строк C++ я уже описывал, а вот тут можно посмотреть, что из неё сделали первокурсники.

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

На данный момент проект содержит менее трёхсот строчек цпп:

ssloy@khronos:~/sdl2-demo/src$ cat *.cpp *.h | wc -l
296

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

Итак, поехали!

Всем доброго дня! С вами Анна Жаркова, ведущий мобильный разработчик компании Usetech. Продолжаем рассматривать способы многопоточный работы в Kotlin Native. В предыдущих статьях мы уже рассмотрели существующие способы работы с многопоточностью с корутинами и без, и что делать с имеющимися болями. Теперь поговорим о новой модели управления памятью, которая появилась совсем недавно.

31 августа компания JetBrains представили превью новой модели управления памятью в Kotlin Native. Основной упор команда разработчиков сделала на безопасность шаринга между потоками, устранение утечек памяти и освобождение нас от использования специальных аннотаций. Также доработка коснулась Coroutines, и теперь можно без опаски переключаться между контекстами корутин без заморозки. Обновления подхватили и Ktor:  

Итак, что же нового появится в версии Kotlin 1.6.0-M1-139: 
1. Заявлено, что мы можем убрать все freeze() блоки (в том числе и во всех фоновых Worker), и переключаться между контекстами и потоками без каких-либо проблем. 

2.Использование AtomicReference или FreezableAtomicReference не приводит к утечкам памяти.

3.При работе с глобальными константами не нужно теперь использовать SharedImmutable.

4.При работе с Worker.execute producer больше не требует возвращать изолированный подграф объектов. 

Однако есть и нюансы: