класна стаття про те, як мережевий пакет проходить крізь ядро Linux від сокета програми до мережевої карти і назад, розбираючи обробку TCP/UDP, маршрутизацію, фільтрацію та черги на кожному етапі

https://www.net.in.tum.de/fileadmin/TUM/NET/NET-2024-04-1/NET-2024-04-1_16.pdf

10% кешбек на ШІ від моно. Хм, може, нарешті перейти з укрсиббанку? 🤔
https://t.me/OGoMono/2690

Це не черговий - yet another paper. Це дуже і дуже цікаво
https://rikiyat.github.io/blog/weight-space-programming

AI може розбиратися у вагах всередині іншої нейромережі і цілеспрямовано змінювати їх, щоб виправити її поведінку. Приблизно як програміст читає та виправляє код.

Як потрапити в Anthropic

Днями говорив з студентами, як проходить один із технічних етапів в Anthropic на позицію Software Engineering. Це по суті класична кодінг співбесіда власними ручками, де перевіряють вміння застосовувати алгоритми на практиці. Наприклад, нещодавно одна з задач була https://leetcode.com/problems/web-crawler/description/ або реалізувати in-memory базу даних, токенізатор для LLM чи щось подібне, далі розповім.

Влаштовано це так: вам дають одну задачу, вона поділена на чотири рівні, кожен зі своїм набором тестів, і на все відводиться 90 хвилин. Рівні додають нові вимоги до системи і зазвичай помітно її ускладнюють. Поки ви не пройшли тести поточного рівня, до наступного не переходите. Задача від початку поставлена так, що розв’язати її повністю навряд чи вдасться, тому якщо ви реалізували більшу частину і пояснили, як систему буде допрацьовано до кінця, то це вже хороший результат.

Розберу одну таку задачу - банківську систему. Вона лежить у відкритому доступі на гітхабі. Спочатку просять реалізувати три операції: створити рахунок, покласти гроші, переказати між рахунками. Далі додається рейтинг - топ-N рахунків за сумою вихідних операцій. На третьому рівні з’являється нарахування кешбеку: два відсотки від суми покупки надходять на рахунок через добу, і для кожного платежу потрібно вміти сказати, чи вже відбулося нарахування. А на останньому просять об’єднати два рахунки в один зі збереженням обох історій і повертати баланс рахунку на будь-який момент у минулому.

Переписувати своє рішення в процесі — нормально, задача на це і розрахована. Але якщо ви від початку погано спроєктували систему і для додавання нової фічі доводиться переписувати все з нуля, то по часу ви навряд чи вкладетеся.

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

За годину, о 18:30, проводжу зустріч-знайомство для потенційних учасників курсу Algorithms in Practice. Вхід вільний за посиланням. Приєднуйтеся :)

Цей курс - більше, ніж просто алгоритми. Він не про запам’ятовування патернів, а про розвиток інженерного мислення та навичок розв’язування надскладних задач. Про програмування загалом і красу побудови елегантних та швидких рішень.

І, звичайно, як бонус - це можливість підготуватися до класичних технічних співбесід у найкращі компанії світу. Думаю, такі співбесіди нікуди не зникнуть. Радше з’являтимуться окремі секції, на яких перевірятимуть уміння працювати з ШІ, - так само, як у пілотів перевіряють навички взаємодії з автопілотом. А фундаментальні знання перевірятимуть і надалі, адже поява нових інструментів не скасовує потреби розуміти, як усе працює.

Що відрізняє розробників, які швидко зростають у кар'єрі?

Одразу скажу - це суб'єктивне спостереження. Я не проводив досліджень і не збирав статистику. Це просто мій досвід, колег та знайомих в IT за останні роки.

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

Натомість у них майже завжди є три інші якості.
1️⃣ Перша - відповідальність.
Почуття відповідальності - це суперважливо. Як правило, такі люди беруть завдання і доводять його до результату. Не шукають виправдань, не перекладають, не розповідають, чому щось не вдалося. Не відмовляються від складних завдань.

2️⃣ Друга - ініціативність.
Вони постійно щось пропонують, обговорюють, покращують. Не чекають вказівок згори, а самі намагаються зробити продукт, процес або команду кращими. При цьому вони можуть свої ідеї спокійно обґрунтувати та пояснити для решти команди. Відповісти на питання, сприйняти критику. І не мовчать, коли хтось генерує аі-слоп у вигляді документації/коду/ітн. Зрештою, команда починає рівнятися на таку людину. Загальна інженерна культура росте; А, так, такі люди не тільки критикують код-рев'ю, а і ставлять лайки за класні рішення.

3️⃣ Третя - мислення з погляду бізнесу.
Вони думають не лише про своє завдання, а й про те, як їхня робота впливає на продукт, користувачів і компанію загалом. Мені здається, саме ці якості найчастіше відрізняють людей, які зростають швидше за інших.

Хоча, можливо, я помиляюся і просто бачу закономірність там, де її немає. А як у вас?

Прям аж не віриться 😵 або як зайти на чужий сервер без пароля (якщо там Alpine)

https://sshhole.com/

💭 Навіщо читати книги, якщо можна просто запитати у ChatGPT?

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

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

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

Тож час від часу вимикайте компютер. Більше бувайте на природі, дивіться на небо, спілкуйтеся з дітьми, читайте хороші книжки і слухайте хорошу музику. Дайте собі час подумати - і, можливо, наступну відповідь ви знайдете самі, ще до того, як відкриєте ChatGPT.

Щоб не плакать, я сміялась (с) Леся Українка

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

Як пагінація може вбити перформанс

На одній із моїх перших робіт стикнувся з такою проблемою. 95-й перцентиль часу відповіді API виглядав погано: важкі запити піднімали його до секунди і вище. В середньому p95 тримався на рівні 400 мс.

Причому проблема стосувалася не всіх користувачів. Чим більше даних було у клієнта, тим повільніше відповідав API. Сам апі повертав дані для нескінченної стрічки: сторінку даних та їхню загальну кількість.

Почав розбиратися і спочатку перевірив саму вибірку. Запит із LIMIT ... OFFSET ... з індексом працював моментально у всіх клієнтів. А от паралельний SELECT count(*), який я виконував, щоб отримати загальну кількість даних, працював довго. Він використовував ті самі фільтри, як і основний запит, але без LIMIT.

Тоді я ще думав, що count(*) - це дешева операція, яка просто повертає готове число. Але почав розбиратися, зокрема, дивитися код бази даних, і зрозумів, що все не так просто. Це просто лінійний пошук. Щоб порахувати кількість записів, які відповідають певним умовам, база має пройтися по них. У клієнта з кількома сотнями записів це майже непомітно. А от коли таких даних десятки-сотні тисяч, то підрахунок займає суттєвий час.

Тоді виникло просте запитання: а навіщо нам узагалі ця кількість? У нас нескінченна стрічка. Ми ніде не показуємо користувачеві, що в нього рівно 3347 запис. Нам потрібно знати лише одне: чи є ще дані, які можна підвантажити.

Тому вирішив узагалі прибрати count(*) і замість загальної кількості повертати прапорець HasMore. Ідея дуже проста. Якщо розмір сторінки - 20 записів, запитуємо 21. Якщо отримали 21, значить, наступна сторінка існує. Зайвий запис відкидаємо, а HasMore встановлюємо в true. Якщо отримали 20 або менше - дані закінчилися.

rows := query(filter, limit=pageSize+1)

hasMore := len(rows) > pageSize
if hasMore {
    rows = rows[:pageSize]
}
return Page{Items: rows, HasMore: hasMore}

У результаті замість підрахунку всіх записів, які відповідають фільтру, ми читаємо pageSize + 1 записів. За наявності індексу це значно дешевше.

Після цієї зміни середній p95 знизився з 405 мс до 128 мс, а час відповіді перестав так сильно залежати від кількості даних у клієнта.

Мораль цієї історії проста: count(*) не завжди дешева операція. Особливо коли мова йде про великий набір даних із фільтрами. Але для мене головний урок був навіть не в цьому. Ми витрачали ресурси на обчислення значення, яке насправді нікому не було потрібне. Іноді найкраща оптимізація - не придумати, як швидше виконати запит, а зрозуміти, що його взагалі не потрібно виконувати.