macOS *

Все мы любим терминал. Но мало кто помнит наизусть все флаги команды find или как правильно распаковать хитрый архив без гугла. Данный инструмент может помочь избежать данной рутины.

Я мобильный разработчик. Иногда при работе со структурами данных я имею дело с endpoint-ами, иду в вики, нахожу страницу с описанием — и не верю ей. Потому что по опыту знаю: страница описывает API таким, каким он был задуман полгода назад, а не таким, какой он сейчас. Дальше начинается знакомый ритуал: пишу в чат бэкендеру, он отвечает «глянь в сваггере», сваггер сгенерирован из аннотаций и показывает приблизительную картину, реальный ответ с сервера от неё отличается, потому что правило сериализации живёт в одном месте, а правило генерации описания — в другом. В итоге я делаю то, что делает большинство клиентских разработчиков: дёргаю endpoint «вживую», смотрю реальный JSON и верю только ему. То же самое бывает и при работе с внешними API (в том числе и солидных компаний).

Это и есть проблема источника правды. У нас не один источник, а несколько, и они конкурируют. Вики — это намерение. Код бэкенда — это реализация. Реальный трафик — это факт. И когда между ними возникает расхождение (а оно возникает всегда), цена ошибки ложится в первую очередь на потребителя API: на фронтенд, на iOS, на Android, на десктоп, на внешних интеграторов.

Эту боль на Habr описывали многие. Алексей, Java-разработчик ЮMoney, в статье «Как улучшить межсерверное взаимодействие и сэкономить время разработчика» формулирует её предельно прямо: «Swagger UI, который генерируется автоматом по метаданным классов, показывает очень примерное описание того, что у нас реально отдаётся из API. Поэтому фронты и мобильные разработчики не могут начать разработку, не вызвав endpoint на живую». Это не чья-то личная неаккуратность — это структурный изъян процесса, в котором правда не централизована.

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

Если вы работаете в большой компании и одновременно живёте там, где есть какие-то региональные ограничения на сервисы, у вас почти наверняка две VPN-конфигурации:

рабочая — для доступа к внутренним ресурсам (GitLab, Jira, Confluence и т.д.)

личная — для личных целей

И постоянное переключение между ними — это, мягко говоря, неудобно.

Я сделал приложение NeonDrift — живые обои для macOS на основе Metal-шейдеров. Для базовой работы не нужны сторонние библиотеки, Screen Recording или Accessibility-доступ. Только AppKit, MetalKit и SwiftUI.

В статье разберу как это устроено изнутри: от трюка с уровнями окон до шейдеров и упаковки в .app. Попутно расскажу про баги, которые я поймал в процессе — растянутую плазму на Retina, крэш при первом же запуске упакованного приложения, анимацию, которая сбрасывалась при каждом переключении Space, и фризы на втором мониторе при смене Space на основном.

Главная идея статьи не в том, чтобы сделать ещё один wallpaper app, а в том, чтобы показать как на macOS можно аккуратно совместить AppKit window management, Metal render loop и SwiftUI-настройки без приватных API — и где именно этот подход начинает трещать по швам.

Транскрибируем любое видео локально, прямо на Mac. Бесплатно, приватно, с качеством на уровне платных сервисов. Полный гайд: настройка, скрипт и промпт для саммари

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

На первый взгляд обновление Mac — задача довольно простая. Однако в корпоративной инфраструктуре всегда есть нюансы, игнорирование которых может привести к серьёзным последствиям: от дополнительного времени на траблшутинг до необходимости отката системы из резервной копии. В худшем случае устройство можно превратить в «кирпич», например, если начать обновление MacBook...

После перехода на macOS я не нашёл SSH-клиент, который закрывает мой ежедневный сценарий так же удобно, как WinSSHTerm.

Устал от постоянных компромиссов, сформулировал требования, собрал свой клиент и выложил код в open source.

Репозиторий

По мере погружения в ИИ и вайб‑кодинг, я столкнулся с одним неудобным моментом — отсутствием возможности диктовать на русском языке в некоторых программах. И если OpenAI в своем приложении позаботились об этом, то в Anthropic такой возможности на тот момент просто не оказалось. А мне уже так понравилось, откинувшись на спинку кресла с чашкой чая, надиктовывать промпты без клавиатуры.

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

И какая же идея могла прийти в голову в 3 часа ночи человеку, который полжизни занимается программированием? Ну конечно же — разработать свое приложение.

Посоветовавшись с Claude и GPT, я набросал небольшой план и приступил к разработке.

Поскольку я работаю на macOS, то для начала не стал заморачиваться с мультиплатформенностью и решил делать все на Swift.

Меня, наверное, сейчас поднимут на смех, но сам я и близко не разработчик. Вообще. Так, по-любительски пилю ботов для Telegram через Claude Code: пара вечеров, одна папка с проектом, и оно работает. И вот за этим занятием в какой-то момент возник простой вопрос: а на каком минимально возможном железе все это делать? Топовый MacBook Pro отпал сразу. Все-таки 300к за машину, на которой ты по выходным учишь нейросетку отвечать на стикеры — как-то жирновато. MacBook Air? Ну, возможно. А что если опуститься еще ниже и купить MacBook Neo? Звучит интересно. Но вот потянет ли?..

Это четвёртая статья из серии про инженерные решения в ONEMIX — моём мессенджере на React Native. В предыдущих разбирал трёхуровневый кэш сообщений, Double Ratchet E2E и WebRTC звонки с trickle ICE. Последняя про звонки набрала больше всего просмотров, и в комментариях несколько раз спрашивали про десктоп: «а как у тебя там устроено?».

Сегодня — отдельная статья про desktop‑версию. Сразу скажу: я не использовал React Native for Desktop, не Tauri, не React, не TypeScript. Чистый Electron + vanilla HTML/JS. Это нестандартное решение, и я объясню почему пошёл этим путём, что от этого выиграл, и где это бьёт по голове.

У команды MyBox из Мастерской прошел тест-драйв гипотезы: можно ли сделать воспроизводимый продукт (наш MyBox) на Apple-железе так, чтобы удалённый узел мог криптографически проверить, что перед ним «правильный» продукт, а не подмена с применением админского доступа.

Спойлер: через хэш бинарника не проверяется, это решение отмели на краудсорсинге, а вот предложенное клонирование через ABM/MDM работает, но не элегантно. Вышло скорее размножение через центр, чем красивое p2p‑клонирование.

В конце — ограничения (в том числе про Россию) и почему мы продолжаем считать этот маршрут практичным для PoC/MVP. В комментариях оставили ссылку на разбор других (менее удачных) решений.

Не нашел на хабре информации про эту замечательную опенсорсную программу - Übersicht.
Xочу поделится опытом как у меня получилось решить мою боль с постоянным забыванием, что нужно сделать и что запланировано.
Последней каплей стал случай на работе, когда меня спрашивают про тайминг очередной встречи, я залезаю в рабочий календарь Битрикса - все пусто, говорю да я свободен, а потом через час вспоминаю что на это время записан к зубному и дальше переговоры переносы и прочее, а можно было. бы решить вопрос за 2 секунды.

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

Начну с таск менеджеров.

Я долго искал таск-менеджер, который бы не был просто «еще одним приложением», куда я забрасываю дела и забываю про них. Мне было важно видеть свои задачи, а не вспоминать, что нужно открыть очередную программу и проверить, что там на сегодня.

Календарь в Google — понятно, встречи там. А задачи и напоминания? Todoist, Things, Singularity, напоминания Apple — это все хорошо, но каждый раз лезть в отдельную программу, это лишние 10–15 секунд, которые отбивают всякое желание планировать. Todoist я долго пользовался, почти год но мне не хватало одной важной фишки: Вот Календарь с задачами и встречами и справа тут же окно с не распределенным задачами и можно драгдропом перекинуть их в нужный день и в нужное место.

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

Привет, Хабр! Если вы читаете мои дайджесты, то знаете, что обычно я пишу о развитии проекта far2l — порта Far Manager под Linux, macOS и BSD. Но сегодня случай особый. На прошлых выходных я обещал вам рассказать про f4 — написанный с нуля клон far2l на языке Go.

Сегодня состоялся релиз первой публичной альфа-версии 0.1.1-alpha. В этой статье я расскажу, как я пришел к идее переписать легендарный файловый менеджер, почему выбрал Go, как в этом помогли нейросети и почему современному консольному приложению не обязательно страдать от «наследия предков».

“Семь бед - один ресет”, гласят пословицы прошлого. Если с вашим компьютером что-то не так или вы купили устройство с рук, то надо переустановить систему. Однако, «переустановить macOS» — это не одно действие, а как минимум шесть разных сценариев с разными последствиями для данных, прошивки и работоспособности машины.

В этой статье я разберу все основные методы: от самого быстрого («Стереть контент и настройки») до самого радикального (Restore через второй Mac с DFU-кабелем). 

Вообще‑то, я бэкендер последние лет 20, но недавно остался без работы (и AI тут не причём), решил «замутить» свой «стартап», пока ищу новую работу Java‑программиста. А заодно подтянуть новые технологии, поглубже изучить немецкий и английский и немного развеяться…

Писать приложения под iOS было моим хобби последние лет 10, и пару моих приложений до сих пор постоянно висят в топе в Российском AppStore, но это были всё «игрушки», а захотелось сделать что‑то взаправду стоящее, и так возникла идея написать лучшее (ни больше ни меньше) приложение для изучения языков с помощью аудирования. Точнее, товарищ подсказал идею. А ещё точнее — идея давно была реализована под Андроид, но аналогов под iOS нет, а очень хотелось. И мне, и товарищу:). Да и смартфона с андроидом у меня нет и никогда не было, не судите строго, но не люблю я вирусы и глюки.

Идея следующая: берёте любое аудио на любом нужном вам языке, загружаете в приложение, и оно автоматически (можно так же вручную) разбивает аудиофайл на нужные вам сегменты для «шэдоуинга», аудирования, многократного прослушивания и тому подобного. Аналогов в сторе я не нашёл, точнее, что‑то отдалённо похожее там есть, но без своих настроек, без выбора своего контента для изучения, без красивой визуализации аудио, короче, без всего того, что нам бы хотелось иметь.

Итак, идея есть, какие технологии использовать? В старых моих приложениях был UIKit, Realm/CoreData, и, сториборды. Не судите строго, я как бэкэндер тогда не знал, что использование сторибордов среди «трушных» айосников считается плохим тоном и плохой приметой. Но теперь‑то я решил использовать современные технологии! И выбрал такой стэк: SwiftUI, SwiftData, Speech Framework. Что касается последнего, то он вроде бы доступен ещё с iOS 10, но я решил, что технологии развиваются, и распознавание текста из аудио должно было бы сделать со времени iOS 10 огромный рывок вперёд. Но теперь я не так сильно в этом уверен, и об этом эта моя маленькая статья…

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

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

Чтобы дальнейшее читалось в правильном ключе, надо сразу обозначить, с какой я колокольни. В индустрии я лет пятнадцать с лишним, классический fullstack — повоевал и с фронтом, и с бэкендом. Поднимал серверы на Debian с нуля, в студенчестве из спортивного интереса пересобирал ядро, написал тонны всякого вспомогательного софта на разных языках, в какой-то период даже паял (плохо, на коленке, но всё-таки). Опыта, в общем, накоплено достаточно, чтобы не объяснять, чем отличается компилятор от линкера. И тем удивительнее, что многолетние мои привычки расшатала именно скучная бытовая возня вокруг домашнего принтера за восемь тысяч рублей.

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

Когда Apple добавила вырез (notch) в MacBook, реакция у многих была примерно одинаковая:

он есть — и с ним приходится просто мириться.

В отличие от iPhone, где появился Dynamic Island и вырез стал частью интерфейса, на macOS он до сих пор остаётся пассивным элементом. Он не несёт функциональной нагрузки и никак не взаимодействует с пользователем.

У меня возник простой вопрос:

а что если сделать вырез частью UI, а не ограничением?

Так появился проект DynamicNotch.