Сьогодні повернувся до розробки утиліти для 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. Надіюсь скоро закінчую одну з стейжів, і напишу великий пост, але від Вас мені потрібен актив.

Повертаюсь в режим, скоро буде більше постів.

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

Роботи багато, але продовжую відвідувати конференції, цього разу знову прийшов на конференцію по AWS.

Ще одна співбесіда пройшла. Був дизайн систем + AWS + розмовна англійська. Очікую відповідь наступного тижня

Я пропав на 139 днів...

За цей час відбулось дуже багато чого нового, хорошого та поганого. Сьогодні буду все розповідати

— Lead: Чому не працюєш ?
— Senior: Встанволюються залежності
— Lead: Зрозумів...

Мій сайт на Astro, TypeScript та Svelte містить 3 152 рядки чистого коду (SLOC) у 65 файлах, не враховуючи порожні рядки та коментарі. Майже 85% кодової бази припадає на Astro-компоненти та сувору TypeScript-логіку

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

Назбиравши достатньо практичного досвіду та досліджень, я вирішив оформити все у єдиний академічний документ.

📄 Що за стаття?
«Дослідження мікроархітектурних патернів оптимізації та низькорівневої продуктивності програмного забезпечення». У ній розглядаються речі, які часто залишаються за кадром бізнес-логіки: ієрархія пам'яті (AoS vs SoA), кеш-когерентність і проблеми False Sharing, конвеєр CPU та Branchless-програмування, паралелізм рівня інструкцій (ILP) та моделі пам'яті (Acquire/Release бар'єри). Усе з прикладами та аналізом компромісів (Trade-offs).