prefetch_related в Django

Недавно займався код-ревю Django проєктів і постійно бачив одну й ту ж проблему — N+1 запит. Для прикладу, ви робите один запит, щоб дістати 100 оголошень у вашому маркетплейсі, а потім ще 100 додаткових запитів, щоб дістати дані про магазин по кожному оголошенню. Сумарно у вас виходить 101 запит 😨: ваша база навантажена, клієнти довго очікують відповідь від сервера і ви прогріваєте повітря марною роботою.

В Django таку проблему легко може не помітити навіть досвідчений розробник, оскільки в Django ORM об’єкти є “розумними” і якщо ви дістаєте атрибут підв’язаної моделі, то Django зробить додатковий запит, щоб дістати підв’язану модель. Найлегше такі речі віднайти рев’юверу в циклах, де спочатку автор дістає список чогось з бази даних, а потім, обробляючи список у циклі, дістає підв’язану модель:

products = Product.objects.all()
for product in products:
print(product.shop.name)

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

Найлегше вирішити цю проблему, додавши .prefetch_related до запиту, який дістає список чогось (або .select_related, якщо ви розумієте різницю між цими методами). Метод .prefetch_related зробить додатковий запит і дістане всі підв’язані моделі одним запитом і покладе у внутрішній кеш. Унаслідок чого Django зробить два запити: один, щоб дістати оголошення, а один, щоб дістати магазини :

Products.objects \
.prefetch_related('shop') \
.all()

Щоб уникнути N+1 запиту в майбутньому, треба, в першу чергу, знати про таку проблему, можна спробувати тестувати кількість запитів або, найпростіше, при локальній розробці запускати базу в режимі логування всіх запитів і уважно слідкувати, щоб там не було сотні однотипних запитів.

Монгольське письмо

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

Для таких мов не достатньо просто розвернути текст дзеркально, ще треба розвернути всі елементи інтерфейсу. Але зробити це треба теж розумно, бо число записане як “54321” в арабській мові, не повинно стати “12345”, латинський текст посеред такого письма теж не потрібно розвертати, але вирівняти треба вже по іншу сторону. Ну і зображення не треба відзеркалювати, але частина іконок все ж таки має бути на новий лад, і т.д.. Дуже добре про ці нюанси описано в настановах від Apple і Google для їхніх дизайн-систем.

Так-от недавно дізнався факт, що Монголія на офіційному рівні поступово відмовляється від кириличного письма і переходить до традиційного монгольського, яке записується з верху до низу, зліва на право 😱. При чому текст виглядає, ніби його перевернули на 90°, а не вишикували літери зверху донизу, саме тому весь інтерфейс теж має виглядати, ніби його повернули на 90°. Для прикладу вебсайт президента Монголії має горизонтальну прокрутку сторінки, заголовок зліва і підвал з правого кінця. Звісно ж UI фреймворки таке письмо не підтримують, тому монгольським розробникам хіба можу побажати терпіння і наполегливості. Мрію колись побачити як має виглядати монгольський варіант телеграму і інстарграму.

Інструменти для Кафки

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

🚀 provectus/kafka-ui — вебінтерфейс для брокера. Сервіс вміє працювати з декількома кластерами одночасно, можна переглядати та створювати повідомлення 🔥, редагувати топіки та інше. Дуже зручно, якщо цей сервіс піднятий для Кафки на рівні компанії для тестового чи продуктового середовища (якщо безпека дозволяє) і з доступом через LDAP чи GoogleAuth. В такому випадку можна не налаштовувати авторизацію в самій Кафці для різних користувачів, особливо якщо у вас не налаштована взагалі (100% не налаштовано). Також розробникам чи тестувальникам не потрібно буде налаштовувати ніяких додаткових інструментів.

✈️ deviceinsight/kafkactl — консольна програма, щоб працювати з Кафкою. Вміє все що й очікувалося від такого інструменту: переглядати/створювати/редагувати топіки, зчитувати чи публікувати повідомлення, автодоповнення і т.д. Для мене особисто, зручним відкриттям став файл конфігурації, в який можна додати декілька кластерів з різними налаштуваннями та перемикатися між ними командою:

kafkactl config use-context <context>

strace

Не пам’ятаю хто і коли мені показав утиліту strace, але вона вже не раз мене виручала в ситуаціях, коли якась стороння програма не працює і вже не залишилося ніякої надії на те що вона взагалі може працювати. strace — це утиліта для Linux, якою можна відслідкувати які системні виклики робить програма, а це, на хвилинку, будь-яка робота з файлами, з мережею, з процесами, з потоками і тд. Глянувши на список системних викликів, які робить програма, часто буває більш ніж достатньо, щоб зрозуміти як вирішити проблему.

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

access("/var/config.yalm", R_OK) = -1
ENOENT (No such file or directory)

Бібліотека не змогла зчитати файл з налаштуваннями, бо я зробив помилку, вказавши не правильну назву файлу 😂. Помилку виправив і все запрацювало

TODO

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

Однак я не розумію чому люди намагаються боротися з TODO коментарями, додаючи обмеження на кількість тудушок у проєкті, призначаючи відповідального чи встановлюючи дедлайни. Читав на Medium, що компанії навіть пишуть slack бота який звітує про кількість доданих і вирішених TODO.

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

Не розводьте бюрократію у ваших бірюзових компаніях і буде вам щастя 👨‍💻

Емейл чи імейл

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

Також на сайті проєкту «Словотвір» знайшов голосування за український відповідник цьому запозиченому слову і там зараз лідирує е-пошта і е-скринька.

Тому для себе вирішив так:
⁃ email – ні ⛔️
⁃ емейл – ні 🤔
⁃ імейл – топ 😌
⁃ е-пошта – для патріотів 🇺🇦🫡

*картинку взяв з проєкту «Мова – ДНК нації»

Адмінки

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

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

В цей момент, коли бізнес вирішує робити адмінку, я агітую за low-code/no-code конструктори адмінок. За останні два роки з‘явилося десяток рішення з відкритим кодом: appsmith, ToolJet, Budibase та інші. Також є Retool, який зараз де-факто стандарт серед комерційних рішень.

Основна перевага, що такі адмінки набагато швидше робити, ніж кодити їх вручну. А як бонус можна найняти дешевше розробника чи підрядника для розширення таких адмінок або ж взагалі запропонувати комусь з не ІТ-шних співробітників підтримувати адмінку.

Поки я ще в жодному продукті не зміг продати ідею, щоб ми не кодили адмінку вручну. Але це тільки поки! 👨‍💻

Captive portal

Помітив, що за кордоном, коли підключаєшся до публічного WiFi, то майже завжди відкривається сторінка на якій треба ввести свій імейл чи погодитися з правилами користування. Ці сторінки ще відомі як “captive portal” і щоб автоматично така сторінка відкривалася, роутер перехоплює HTTP запити та перенаправляє користувача на потрібну йому сторінку, якщо це потрібно.

Але по суті таке перехоплення нічим не відрізняється від men-in-the-middle атаки,  де роутери, що передають ваш запит, можуть підслуховувати чи підміняти вміст сторінки. Щоб захиститися від цієї атаки, свого часу й придумали захищений HTTPS на заміну HTTP.

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

Так от недавно відкрив для себе сайт, який завжди працює лише через HTTP http://neverssl.com. І тепер, коли я бачу помилку сертифікату при підключенні до публічного Wifi, то ввожу цю адресу у браузері, далі роутер робить свою зловмисну роботу, перенаправляє мене на свою сторінку входу, я підписуюся на всю рекламу, яку мені пропонують, і отримую свою порцію безкоштовного інтернету на 30 хвилин.📶