Сьогодні хочу поділитися невеликим експериментом із low-level програмування на macOS – це Data Link Sniffer, простий sniffer Ethernet/Wi-Fi, побудований на основі BPF (Berkeley Packet Filter).

Ідея дуже проста, але водночас демонструє роботу з мережею на найнижчому рівні: ми читаємо сирі Ethernet-фрейми з мережевого інтерфейсу, а потім виводимо MAC-адреси відправника та отримувача і тип кадру (EtherType).

Технічно, програмі потрібні лише:
- macOS,
- права root (щоб отримати доступ до /dev/bpf*),
- компілятор Clang.

Після компіляції (make) та запуску (sudo ./bpf_sniffer) можна спостерігати трафік у реальному часі. Варто пам’ятати, що на Wi-Fi в managed mode ви не побачите всі підключені пристрої для цього потрібен monitor mode. І ще невелике зауваження: іноді macOS може виводити попередження про BIOCSETBUFSIZE – його можна ігнорувати.

Цей проєкт чудовий приклад того, як низькорівневе програмування дозволяє отримати доступ до мережі на рівні кадрів, обходячи високорівневі API. Для тих, хто цікавиться мережею, BPF і системним програмуванням, це відмінний старт/

Github Repo:
https://github.com/DenysSkobalo/bpf_sniffer

Три тижні тому в мене прийшла ідея зробити маленьку утиліту для macOS: щоб клавіатура автоматично переключалась залежно від активного додатку. Наприклад, коли я відкриваю Telegram — розкладка українська, а коли відкриваю термінал — англійська. Потім я трохи забив на цю ідею… і ось учора вирішив нарешті реалізувати її.

Ідея виявилась цікавою, бо на перший погляд здається простою, але насправді довелось продумати декілька речей: як відслідковувати активний додаток і як переключати розкладку клавіатури у реальному часі.

Розробка йшла поетапно:
1. Моніторинг активного додатку
Спочатку я пробував різні способи отримати назву активного вікна. Виявилось, що найстабільніше працює NSWorkspace.sharedWorkspace().frontmostApplication через Objective-C код. Це стало основою модуля macos_bridge.m, який підключений до C-проєкту через заголовки macos.h та macos_bridge.h.
2. Зміна розкладки
Наступний крок — переключення розкладки клавіатури. Для цього я реалізував функцію set_keyboard_layout, яка працює через TIS (Text Input Source) API macOS. Тепер можна задавати ідентифікатори розкладок на кшталт com.apple.keylayout.ABC чи com.apple.keylayout.Ukrainian-PC.
3. Парсер JSON правил
Щоб користувач міг налаштувати, яка розкладка для якого додатку, я реалізував власний парсер JSON-файлу rules.json. Він читає конфігурацію правил у C, виділяє назви додатків та потрібні розкладки. Наприклад:

{
  "rules": [
    {"app": "kitty", "layout": "eng"},
    {"app": "Telegram Desktop", "layout": "ua"},
    {"app": "Google Chrome", "layout": "eng"}
  ]
}

Функція apply_rules_to_active_window перевіряє активний додаток і застосовує потрібну розкладку у реальному часі.

На даному етапі утиліта поки що в розробці, і готова лише підутиліта ADA (auto-detected-app). Вона вже може відслідковувати активний додаток та виводити debug-вивід із застосованими правилами розкладки.

Власна проблема з постійним переключенням розкладки перетворилась на окремий проєкт.

https://github.com/DenysSkobalo/macos-input-switcher

Зараз активно введеться розробка проєкту "MIS", і вже відбулося кілька важливих змін і покращень:

1. Повна інтеграція C та Objective-C
Тепер проєкт компілюється як єдиний бінарник, де C-логіка і Objective-C код (для macOS API) працюють разом без “костилів”. Тепер усі модулі, включно з відслідковуванням активного додатку і управлінням клавіатурою, компілюються через один Makefile і збираються у повноцінний .app.

2. Нова система правил
JSON-конфіг rules.json отримав оновлення: додав підтримку нових додатків і точних ідентифікаторів розкладок. Наприклад, тепер можна задати:

{
  "rules": [
    {"app": "kitty", "layout": "com.apple.keylayout.ABC"},
    {"app": "Telegram", "layout": "com.apple.keylayout.Ukrainian-PC"},
    {"app": "ChatGPT", "layout": "com.apple.keylayout.Ukrainian-PC"},
    {"app": "Google Chrome", "layout": "com.apple.keylayout.ABC"}
  ]
}

3. Новий модуль layout_switcher
Реалізована централізована логіка зміни розкладки. Тепер не потрібно окремо викликати API для кожного додатку — функції layout_switcher_init та layout_switcher_free керують усім циклом переключень, економлячи ресурси та мінімізуючи затримки.

4. Відмовились від старого модуля auto-detected-app
Раніше я робив окремий агент, який тільки виводив debug-інформацію. Зараз він повністю інтегрований у головний бінарник, і відстеження активного додатку працює у фоновому режимі без додаткових процесів.

Результат: зараз утиліта вже збирається в готовий .app, автоматично підтягує правила з rules.json і змінює розкладку під час роботи з будь-яким додатком. Тестування показує, що переключення практично миттєве, а CPU навантаження мінімальне.

https://github.com/DenysSkobalo/macos-input-switcher/commit/57a66c3f9722924648c261f00abee2403d079240

Сьогодні день був так сказати проведений в резюме та LinkedIn. Але по закінченю, я загадав що у мене є ігровий ноутбук, який я вже не використовую. І в голову прийшла думка, а якщо я з нього спробую зробити сервер для своїх пет-проєктів. Ну і з цього почалось 4-годинне занурення як Sysadmin & DevOps.

Спочатку, я зробив загрузочну флешку з Ubuntu Server. Вставив в ноутбук, зніс до біса Windows (дратує Windows), встановив на свою машину Ubuntu Server Minimized, без GUI і лишнього сміття.

Далі, підключення до Wi-Fi. А це окрема проблема тому, що я живу у гуртожитку та немаю Ethernet кабелю. Хвилин 10-15, почитавши про netplan, написав конфіг для підключення до Wi-Fi і все, доступ отриманий. Після цього йшла Linux-рутина,

sh sudo apt update && sudo apt upgrade -y

, далі встановлення базових інструментів. З головного це nvim, я зрозумів, що я без нього як без рук, якщо йдеться про написання коду, конфігів. А потім я згадую, що якщо я буду не вдома а доступ до "сервера" треба буде отримати, я встановлюю та налаштовую OpenSSH. Одразу пересідаю за свій Macbook та підключаюсь до нього через ssh і продовжую налаштування "сервера". А да доречі, ще зробив таку структуру:

/srv/docker    # for Docker container
/srv/projects  # for my projects
/srv/volumes  # for saved Docker volumes

Отже, далі в діло вступає DevOps engineering, встанволення базового так сказати для базових проєктів, це Docker. Налаштував, конфіг Docker'а, щодо директорій, щоб все було в одному місці. Думав k8s ще встановити, але у мене таких проєктів немає, щоб використовувати кластеризацію, тому я думаю, що у майбутньому встановлю, пограюсь з ним. Потім для Docker, налаштував інтерфейси та вільні порти. Також ще встановив docker-compose, щоб ну взагалі було пофеншую.

Сервер, посуті вже працює, але треба ж протестувати.

mkdir -p /srv/projects/myproject

, далі відкриваємо мій улюблений NVIM, і починаємо. Доречі я на Golang, вже не писав більше 2-х місяців, і щоб я писав 10хв, http server на GET запит використовуючи фреймворк це стидно, тому я думаю, що після двох проєктів на С, я повертаюсь до Golang. Отже я написав httpserver на одну GET ручку, де в response буде перше програмістське слово "Hello ....". Доречі на Golang я то не писав більше 2-х місяців а ось Dockerfile, docker-compose взагалі рік. У висновку думаю, погрішу сьогодні трохи, ChatGPT на базу. Отримую я і Dockerfile, і docker-compose. Піднімаю container, роблю локальний запит ніби працює, а тепер хочеться, щоб можна було запит робити не залежно чи в локальній мережі чи ні, я перевіряю публічний IP адрес, copy-paste + порт, enter, і ... НІ*УЯ.

Я нічого не отримую, запит просто зависає, я в логи до контейнера, там все нормально, я не розумію, що не так, ну не може бути, що десь в 15 рядках коду міг помилитись. Дивлюсь, та ніби все нормлально. Вирішую, якщо погрішив раз можна і другий, і до чата, пояснюю всю ситуацію від А до Я, а він каже що скоріш всього провайдер гуртожитку стоїть Firewall/ISP blocking. І я починаю далі думати, як вирішити питання, єдина робоча гіпотеза TUNNEL. Альтабаюсь до чату, щоб спитати, які є тунелі, бо я памятав тільки ngrok, а мені хотілось чогось нового спробувати, і я бачу що чат запропонував те саме що і я, одразу після повідомленння того, що скоріш всього є Firewall.

Я вибрав Cloudflare Tunnel, запригнув в доку, встановив CLI, думаю попрошу чата покращити docker-compose, щоб автоматично після ребута контейнера піднімав тунель. У висновку все вийшло, і тепер можна буде тестувати свої проєкти на власному сервері. Але єдине, що мене не влаштовує, що URL хаотичний а точніш domain , просто набір слів,но так як я не планую деплоїти щось серйозне, то безріниці.

На майбутнє планую спробувати, ще пдіняти на сервері БД, а потім вазгалі спробувати задеплоїти проєкт, де буде мікросервісна архітектура + RabbitMQ + DBs, і можливо як я згадував k8s. Ось так один вечір я побував Sysadmin + DevOps, та іноді один вечір з Linux дає більше, ніж тиждень туторіалів. Але у висновку цей вечір ще раз показав, що більшість знань приходить не з книжок, а з моменту, коли щось не працює, і ти змушений розбиратись, чому саме.

Сьогодні повернувся до розробки утиліти для MacOS. Подивився на свій парсер JSON та сказав "Що за це гавнокод, треба рефакторити", але посуті воно виконувало те що мені треба було, но якщо правила будуть маштабуватись то все може полетіти. І я прийняв рішення, не брати готову бібліотеку для парсинга JSON на С, а написати своє, ну коротше кажучи все як завжди в мене.

Але яка різниця ж була між тсарим "парсером" та новим паресром. Старий парсер, реалізовував парсинг "на пальцях" так сказати, тобто кожен масив/об’єкт шукали вручну {, }, [, ], ключі та значення. Потребував багато ручного виділення памяті і вільного звільнення для кожного ключа/значення. Також Код був крихкий, не перевіряв коректність JSON, та легко ламався на додаткових пробілах, комах чи змінах формату JSON. Фактично обробляв рядок як текст, а не як структурований JSON.

В свою чергу новий парсер використовував окремий структурований Parser, який працює з токенами (`TOKEN_STRING, TOKEN_COLON, TOKEN_LBRACE etc.`). Тобто розбиває JSON на токени: key, value, дужки, коми, двокрапки. Це дозволяє легше і надійніше опрацьовувати формат. Також присутні функції, які забезпечують контроль за синтаксисом, це praser_expect та parser_advance. Ще парсер, парсить масив та об’єкти окремо через parse_rule_array(&parser, cfg); , parse_rule_object(&parser, cfg);. Найголовніше для мене це те, що новий парсер мінімізує ризик витоків памяті та дублювання коду. Централізоване виділення strndup для key, value. І легше додавати нові ключі в JSON або змінювати структуру.

Новий парсер працює за таким планом:
1. Файл читається в память як рядок (тепер замість ручного сканування символів, весь JSON передається структуровано парсеру)
2. Ініціалізація парсера, встанволює початкову позицію у рядку, а також зчитує перший токен. Токени - це типізовані частини JSON.
3. Перевірка головного об’єкта, парсер очікує, що JSON починається з {. Якщо ні, то парсер видає помилку.
4. Читання ключів верхнього рівня, парсер перебирає ключі верхнього рівня у JSON. Для кожного ключа, зчитує його та перевіряє, чи це ключ "rules".
5. Парсинг масиву правил, якщо знайдено "rules", парсер далі очікує [ початок масиву правил. Потім перебираємо об’єкти правил, де для кожного об’єкта у масиві викликається parse_rule_object.
6. Парсинг окремого правила, знову парсер очіує {, потім ініціалізуємо змінні :

char *app_name = NULL;
char *layout = NULL;

Перебирає всі пари key-value у об’єкті, якщо токен це рядок це ключ ("app" або "layout"), потім `parser_advance` для переходу до двокрапки, зчитуємо значення після :, в залежності від ключа, присвоюємо значення app_name або layout. Після закінчення об’єкта }, виділяємо память у масиві cfg->rules та зберігаємо нове правило.
7. Завершення мсиву та JSON, після всіх об’єктів очікуємо ] (кінець масиву), потім } (кінець JSON), файл звільняється, структура RulesConfig готова до використання.

8. В результаті, в RulesConfig зберігається :

cfg->rule_count  // кількість правил
cfg->rules[i].app_name  // ім’я додатку
cfg->rules[i].layout    // розкладка для цього додатку

Тепер можна викликати layout_switcher_init(cfg) і автоматично створювати таблицю відповідності додатків до клавіатурної розкладки.

Ось так потратив сьогодні 4 години на написання власного JSON Parser. Але також без тупих моментів сьогодні. Закінчив писати парсер, перекурив, тепер час перевіряти як працює моє творіння. Замінив парсер, комплюю бінарник, запускаю все працює, тільки для Google Chrome розкладка не змінюється, я думаю ну не може бути, що я десь помилився. Починаю дебажити, дивлюсь парсить все правильно, думаю може проблема в агенті layout_switcher, але я памятаю що до нового парсера все працювало, у чому тоді проблема. В правилах я памятаю, що поставив українську розкладку для Google Chrome, але вона не міняється, читаю далі код, перевіряю, дебажу. І не можу зрозуміти чому усі правила працюють а для Google Chrome ні.

Щоб ви розуміли, я передивився кожен файл, кожен рядок, але файл з правилами ні. Відкриваю, дивлюсь а там для Google Chrome, стоїть правило, що коли активний Google Chrome автоматично світчнути на англійську розкладку а не на українську як я думав, що я написав.

І після моєї необаності, все працювало правильно. Я зробив висновки сьогоднішньої роботи, це зрозуміти, що правильна структура та контроль синтаксису заощаджують час у майбутньому і спрощують масштабування. Також важливо перевіряти логіку правил і конфігурацій, перш ніж шукати помилки у коді, бо іноді «проблема» виявляється банальною у самому файлі правил.

Так як останнім часом, пости виходь великі за об'ємом, я вирішив спробувати використати сервіс Telegraph. Тому тримайте, 4-й девлог по розробтці утиліти на macOS.

https://telegra.ph/Devlog-4-TrackMyLayout-Utility-01-02

Новий рік почався, з того, що я вперше купив власний domain. На даний момент очікую зміни nameservers, це займає до 24-х годин, поки вони поширяться по всьому Інтернету. Після цього Cloudflare стане автоматично моїм DNS-провайдером.

Можете вітати ! Підтвердження пройшло досить швидко, і тепер при перевірці через команду dig мені повертається A-запис, IP-адрес на який вказує домен, а саме IP мого сервера, і також повертається CNAME-запис для піддомену www, показує, на що він перенаправляє, у мене це мій домен denysskobalodev.space, що означає denysskobalodev.space просто "переходить" на корневий домен.

Якщо не помиляюсь, сьогодні День програміста, тому всіх причетних вітаю, бажаю ні багів, ні факапів, але інкрізів та дей оффів

Вибачаюсь, що пропав, останні дні працюю над останнім проєктом для університету.

Залишилось ще два дні до дедлайна, повинен дописати документацію, та почистити трохи код і все.

Смішно те, що більшу половину роботи над цим проєктом, я робив все на колінці + юзав ChatGPT. Хотів чим бистріше здати цей проєкт, але коли почались проблеми з кінцевим результатом, я почав шукати книжки, статті про Компʼютерний зір, перекладати їх з гпт, та читати, щоб розуміти як покращити результат системи.

Вже роки 4, не брав книжку про CS.

3:05am | На фото, сижу пишу документацію. Вже більше 20 сторінок…

Добрий ранок … Хахахах поспав трохи приблизно 5 години, можна сідяти працювати

Не вже це сталось, мені потрібно було 13 не повних днів, щоб я вперше задеплоїв на свій сервер тестовий бекенд, і це працює. Пізніше напишу детальніший пост як це бути Platform Engineer, Site Reliability Engineer, SysAdmin, Cloud Architect, Software Architect, Solutions Architect 😅.

Раніше я деплоїв фронтенд, бекенд та RabbitMQ на Vercel+AWS, але у моєму випадку це мій сервер, індивідуальне налаштування, вирішення проблем, тунелювання і так далі.

Ви тепер можете відвідати:
https://denysskobalodev.space

Доречі відновив свої походи на конференції. Минуло тижня ходив на коференцію по AWS, розповідали про нові функції, що добавили в AWS, про лямбду розказували та про AI який розвиває Amazon. Так як я в пошуках роботи, то нетворкінг на таких мітапах те що потрібно. Познайомився з спікерами, один з них Solutions Architect, а другий Cloud Architect і Founder стартапу. Поспілкувались трохи про AWS, мені дали декілька порад для апруву як архітектору.

Сьогодні також ходив на конференцію, по вебу в одну Ліонську компанію. Була презинтація по RDF, було цікаво бо раніше я чув про RDF, але завжди не мав часу, щоб розібратись з цією темою. Одним словом було цікаво.

Незнаю як в Україні, але у Франції після таких заходів, завжди організатори замовляють піццу, напої іноді пиво буває, і після виступу усіх спікерів, ми йдемо у залу і спілкуємось, випиваємо, їмо.

І сьогодні я познайомився з тех. рекрутером компанії у якій проходила конференція. Поспілкувались, обмінялися LinkedIn, потім підключились розробники, поговорили загально про веб, нові технології.

Якось ось так, порада для Вас, якщо Ви хочете розвиватись як розробник, або як інший фахівець з ІТ, потрібно відвідувати такі заходи, і знайомитись з людьми, це розвиває багато скілів.

Прошу вибачення, що не написав пост, я тут готую великий проєкт, потримаю інтригу. Якщо коротко, то зараз на посаді CTO/Chief Architect, працюю з CPO. Надіюсь скоро закінчую одну з стейжів, і напишу великий пост, але від Вас мені потрібен актив.