Привет! Я Алексей, iOS-разработчик в Тинькофф. Участвую в развитии архитектуры приложения, провожу собеседования и занимаюсь менторингом разработчиков.

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

Представляю вашему вниманию перевод моей статьи из блога Проекта Darling. Маленькая справка по используемым понятиям: Darwin – операционная система с открытым исходным кодом, лежащая в основе macOS, iOS и других ОС от Apple; Mach-O – бинарный формат исполняемых файлов и библиотек, использующийся в Darwin; dyld – динамический загрузчик, использующийся в Darwin для загрузки файлов Mach-O; dylib – динамически загружаемая библиотека (обычно имеет расширение .dylib).

Цель Проекта Darling – сделать возможным запуск macOS-приложений под Linux, и умение загружать бинарные файлы в формате Mach-O – один из ключевых шагов к достижению этой цели.

Исходно, Darling был выстроен вокруг собственной реализации загрузчика Mach-O и идеи транслирования вызовов между высокоуровневым Darwin API и его Linux-аналогами. С тех пор наш фокус сместился на запуск кода во всё более и более изолированном Darwin-контейнере. С тех пор как мы перешли на использование Mach-O для внутренних компонентов Darling, у нас появилась возможность использовать исходный dyld от Apple, а также собирать многие другие компоненты Darwin с открытым исходным кодом. Нам всё ещё нужен простой загрузчик Mach-O, чтобы загружать сам dyld.

Создание кастомного сервиса и тем более клиента Bluetooth Low Energy – прогулка по граблям с завязанными глазами. По крайне мере так было для меня 4 года назад, когда я только начинал работать с BLE-устройствами. Сейчас почти каждый мой проект предусматривает использование этого протокола, поэтому в свое время пришлось в нем долго и мучительно разбираться. 

Разложить все по полкам помогла книга Мохаммада Афане "Intro to Bluetooth Low Energy" и серия постов на Novel Bits. Лично для меня эта книга стала настоящим открытием. Изначально я делал ее перевод на русский для своих коллег, не имеющим опыт работы с BLE. С согласия автора (огромное ему спасибо) решил опубликовать свою работу здесь. Надеюсь, перевод окажется полезным.

Это первая часть перевода (всего их будет 5), которая рассказывает, что такое BLE, ее возможности и отличия от Bluetooth Classic и описывает архитектуру протокола.

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

Чем этот курс отличается от прочих других? Большая часть кода пишется самостоятельно и выполняется на вполне реальном современном железе. В качестве целевой платформы выбран Raspberry Pi 3 model B. Т.е. достаточно актуальная архитектура AArch64. ARMv8 Cortex-A53, четыре ядра, 64-бита и вот это всё. В качестве основного языка программирования выбран Rust. Который безопасный, быстрый, без GC и так далее. Его, Rust, предполагается изучать во время курса.

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

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

оригинал

Нулевая лаба

Первая лаба: младшая половина и старшая половина

Вторая лаба: младшая половина и старшая половина

Прокрастинацию принято считать разновидностью лени и ерундой, а эффективным лекарством от нее грозный окрик: «Соберись, тряпка!» На деле прокрастинация — опасная проблема, сродни зависимости, которая вызывает много вины и стыда, и способна со временем разрушить личность. Почему она так опасна, редко лечится попыткой «взять себя в руки» и как ее одолеть?

С Вами снова Владимир и меня все еще зовут девопс.

Сегодня делюсь свежеобретенным представлением о создании архитектуры нового проекта или реконфигурации нового.

Немного контекста: я живу в Санкт-Петербурге и работаю в большой компании с крайне бюрократической структурой управления, в которой девопс – это драйвер, лидер и на-все-руки-мастер.

• Я держу гит-репозиторий локально у себя на компе
• Все пароли защищены GPG шифрованием, поэтому даже при получении SSH-доступа к моему компьютеру утечка не повлияет на безопасность

Кратко о том, как создавать ключи, шифровать и подписывать файлы и отправлять ключи на сервер ключей.

GPG (также известный как GnuPG) создавался как свободная альтернатива несвободному PGP. GPG используется для шифрования информации и предоставляет различные алгоритмы (RSA, DSA, AES и др.) для решения этой задачи.

В статье рассказывается о решении задачки с собеса в одну российскую IT-контору.

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

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

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

Одна из фундаментальных тем в разработке под Android это работа с UI. Понимание того, как работает UI не даст многого в практическом плане, зато уменьшит вероятность того, что вы натворите полную дичь.

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

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

Привет, Хабр! В свободное от работы время по вечерам мне нравится воплощать в жизнь свои сумасшедшие идеи. В один из таких вечеров родилась мысль реализовать компилятор кода в машину Тьюринга. Осознав всю тщетность бытия сложность реализации, было принято решение начать с чего-то более простого – симулятора простенького процессора со своим собственным ассемблером, в котором команды выполнялись бы с помощью различных состояний машины Тьюринга, а данные хранились бы на одной ленте. В конечном итоге удалось осуществить практически первоначальную задумку, а именно получить одну единственную машину Тьюринга, способную выполнять скомпилированную из NASM подобного ассемблера программу без какого-либо внешнего взаимодействия.

Меня зовут Николай, я Frontend-разработчик IT-компании Relog. Хочу рассказать о самых распространённых ошибках в вёрстке современных проектов.

Дело в том, что лишь малая часть современных фронтендеров обращает внимание на работу с HTML и CSS, предпочитая готовые решения, вроде UI-библиотек и систем сеток. Но эти решения неидеальные и приходится дописывать обёртки вокруг них, видоизменять код, переписывать стили и совершать прочие действия для соответствия требованиям проекта. Тут-то и начинаются проблемы: вёрстка местами становится избыточной, стили переназначются через important и с каждым релизом проект всё сложней поддерживать. Я уже не говорю об удобстве использования и доступности. Об этом думают вообще в последнюю очередь.

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

Меня зовут Николай и я Frontend-разработчик в логистическом стартапе Relog. Хочу рассказать о самых распространённых ошибках в вёрстке современных проектов.

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

Пара слов о том, что мы будем изучать.

1. Идеальный. От рождения до смерти следить за зубами.
2. Типовой. Обратить внимание на свои зубы в возрасте примерно 30–40 лет. Вылечить кариес, наладить правильную гигиену. Это когда не просто горизонтальными движениями щёткой по зубам. И зайти к ортодонту и ортопеду. Если вы достоверно точно знаете, что с опорным аппаратом зубов у вас всё ОК, то можете пропустить этот шаг.
3. Сложный. Когда вам уже 60 лет и вставную челюсть не хочется. Это, конечно, уже не про экономию, а про съёмные протезы и профилактику пародонтита.

В последнее время всё чаще я ощущаю математическое веяние в программировании. Нет, это не про интегралы с производными, а про что-то абстрактное, другое. Про то, что было всегда у нас под носом, но оставалось незамеченным. Наступит день - про это будут говорить на каждом углу. Но не сегодня. Сегодня мы с этим познакомимся.