Не продав
Перед Різдвом мені в телеграм постукалися з пропозицією купити SweetPad. Я трохи посумнівався, а за пару днів все ж таки вирішив погодитися на умови. Поговорив з бухгалтеркою, і вона сказала, що треба зареєструвати VAT-EU, щоб продати в межах ЄС як B2B. Я з ентузіазмом відразу ж подав заявку у податкову. Але податкова вирішила, що працювати взимку, на свята — це не свята справа. Тільки під кінець березня мені таки зареєстрували той VAT-EU номер, з другої спроби.
Тепер, наче, все готово і можна продавать. Але шось я сів-подумав, і мене таки задушила жаба, що погодився за так дешево подавати розширення🤷♀️ . Воно органічно росте, люди люблять його, навіть донатять якісь там гроші. Тому пішов і в лоб запропонував більшу ціну тому панові, що збирався купляти. Пан передбачувано відмовився, і ми мирно розійшлися в різні сторони. Так я і не продав своє розширення для VSCode, тому нехай росте, може продам комусь за більше 😭
Перед Різдвом мені в телеграм постукалися з пропозицією купити SweetPad. Я трохи посумнівався, а за пару днів все ж таки вирішив погодитися на умови. Поговорив з бухгалтеркою, і вона сказала, що треба зареєструвати VAT-EU, щоб продати в межах ЄС як B2B. Я з ентузіазмом відразу ж подав заявку у податкову. Але податкова вирішила, що працювати взимку, на свята — це не свята справа. Тільки під кінець березня мені таки зареєстрували той VAT-EU номер, з другої спроби.
Тепер, наче, все готово і можна продавать. Але шось я сів-подумав, і мене таки задушила жаба, що погодився за так дешево подавати розширення
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥29❤2🤩1
Forwarded from Стендап Сьогодні
Шифрування на кожний день: AEAD
#Криптографія
В криптографії я повний дилетант. Тому, коли постає задача "щось зашифрувати", очі розбігаються від різних алгоритмів, режимів, жаргону і так далі.
Тому ділюся головним скороченням, яке треба знати: AEAD. Якщо вам потрібно "щось зашифрувати", то оце воно. AEAD попросту значить, що окрім зашифрованого повідомлення, передається також і його підпис — за яким можна підтвердити, що дані не сфальсифіковані. (Цікавий факт: будь-які двійкові дані можна "розшифрувати" за алгоритмом та отримати якийсь відкритий текст. Так що підпис рятує не тільки від фальсифікації, а й просто втрати інформації.)
Але насправді навіть не потрібно знати, що там є підпис, бо його за вас зробить (та перевірить) бібліотека шифрування. (Правило шифрування №1 - не пиши нічого сам!) А от що від нас залежить, так це вибір нонса, який повинен бути унікальним в межах одного ключа. Якщо ви не плануєте одним ключем шифрувати мільярди посилок, то звичайний випадковий нонс влаштує.
Щодо конкретних алгоритмів, то є 2. Золота класика: AES256-GCM. Оптимізований на апаратному рівні, використовується у Wi-Fi, TLS, та багато де ще. Та новий модний ChaCha20-Poly1305 - більш безпечний (як каже інтернет), швидший на ARM, теж використовується у TLS, WireGuard тощо. Обидва алгоритми вас влаштують.
У JWE - це який JWT, але зашифрований — теж, до речі, AEAD.
#Криптографія
В криптографії я повний дилетант. Тому, коли постає задача "щось зашифрувати", очі розбігаються від різних алгоритмів, режимів, жаргону і так далі.
Тому ділюся головним скороченням, яке треба знати: AEAD. Якщо вам потрібно "щось зашифрувати", то оце воно. AEAD попросту значить, що окрім зашифрованого повідомлення, передається також і його підпис — за яким можна підтвердити, що дані не сфальсифіковані. (Цікавий факт: будь-які двійкові дані можна "розшифрувати" за алгоритмом та отримати якийсь відкритий текст. Так що підпис рятує не тільки від фальсифікації, а й просто втрати інформації.)
Але насправді навіть не потрібно знати, що там є підпис, бо його за вас зробить (та перевірить) бібліотека шифрування. (Правило шифрування №1 - не пиши нічого сам!) А от що від нас залежить, так це вибір нонса, який повинен бути унікальним в межах одного ключа. Якщо ви не плануєте одним ключем шифрувати мільярди посилок, то звичайний випадковий нонс влаштує.
Щодо конкретних алгоритмів, то є 2. Золота класика: AES256-GCM. Оптимізований на апаратному рівні, використовується у Wi-Fi, TLS, та багато де ще. Та новий модний ChaCha20-Poly1305 - більш безпечний (як каже інтернет), швидший на ARM, теж використовується у TLS, WireGuard тощо. Обидва алгоритми вас влаштують.
У JWE - це який JWT, але зашифрований — теж, до речі, AEAD.
❤🔥10🔥7
Нова Кафка ➕
Там на днях вийшла нова версія кафки — 4.0
Основна зміна, що повністю прибрали Zookeeper з інфрастуктури. Замість нього тепер за замовчуванням буде використовуватися KRaft mode. В цьому режимі брокери спілкуються один з одним, щоб домовлятися про стан всієї системи, без посередників як це було раніше.
Інша важлива зміна стосується ребалансування консюмерів у групі. Раніше багато відповідальності за ребалансування покладалося на самі клієнтські бібліотеки, через що складно було координувати між собою консюмерів у групі. Типова ситуація, коли один консюмер у групі помирає, розпочинається ребаланс і вся група чекає поки він завершиться. В новій версії клієнти стали «худіші» і відповідальність за групу перенесли на координатора. Обіцяють, що ці зміни зроблять ребаланс супер швидким і точковим:
Якщо цікаво, то раджу почитати тут цілі і мотивацію:
KIP-848: The Next Generation of the Consumer Rebalance Protocol
В цілому там ще купа інших змін, але в більшості з них я не дуже розбираюсь, тому лінка на новину тут
Там на днях вийшла нова версія кафки — 4.0
Основна зміна, що повністю прибрали Zookeeper з інфрастуктури. Замість нього тепер за замовчуванням буде використовуватися KRaft mode. В цьому режимі брокери спілкуються один з одним, щоб домовлятися про стан всієї системи, без посередників як це було раніше.
Інша важлива зміна стосується ребалансування консюмерів у групі. Раніше багато відповідальності за ребалансування покладалося на самі клієнтські бібліотеки, через що складно було координувати між собою консюмерів у групі. Типова ситуація, коли один консюмер у групі помирає, розпочинається ребаланс і вся група чекає поки він завершиться. В новій версії клієнти стали «худіші» і відповідальність за групу перенесли на координатора. Обіцяють, що ці зміни зроблять ребаланс супер швидким і точковим:
Ideally, a consumer should not be impacted at all by a rebalance if its assignment is not changed.
Якщо цікаво, то раджу почитати тут цілі і мотивацію:
KIP-848: The Next Generation of the Consumer Rebalance Protocol
В цілому там ще купа інших змін, але в більшості з них я не дуже розбираюсь, тому лінка на новину тут
Please open Telegram to view this post
VIEW IN TELEGRAM
❤🔥10🔥8👨💻1
Chores buddy
Недавно на роботі розмовляв про AI-тули для розробки. Я накинув думку, що класно було б, якби хтось навчив AI класно робити якусь монотонну-шаблонну роботу. Наприклад, проходитися по проєкту і переводити JS на TS. Або модуль за модулем покривати тестами. Туди ж підійшли б всякі штуки типу обгортати рядки в коді для перекладу, переводити з однієї бібліотеки на іншу, покривати API OpenAPI-документацією і тому подібне. На такі «прибирання» важко знайти час, але мені подобається працювати в проєкті, де все в одному стилі і на своєму місці.
Вийшов би такий собі бот-прибиральник — наводив би ночами красу, а зранку присилав би невеликі пул-реквести на 5–10 файлів кожен. Щоб можна було відносно швидко передивитися код і легко втрутитися, щоб підправити якісь помилки. Знаю, що є Devin, але я не пробував його і хз, наскільки він під такі монотонні задачі заточений, але дивився огляди на YouTube, і відгуки по ньому поки що так собі🧹
Недавно на роботі розмовляв про AI-тули для розробки. Я накинув думку, що класно було б, якби хтось навчив AI класно робити якусь монотонну-шаблонну роботу. Наприклад, проходитися по проєкту і переводити JS на TS. Або модуль за модулем покривати тестами. Туди ж підійшли б всякі штуки типу обгортати рядки в коді для перекладу, переводити з однієї бібліотеки на іншу, покривати API OpenAPI-документацією і тому подібне. На такі «прибирання» важко знайти час, але мені подобається працювати в проєкті, де все в одному стилі і на своєму місці.
Вийшов би такий собі бот-прибиральник — наводив би ночами красу, а зранку присилав би невеликі пул-реквести на 5–10 файлів кожен. Щоб можна було відносно швидко передивитися код і легко втрутитися, щоб підправити якісь помилки. Знаю, що є Devin, але я не пробував його і хз, наскільки він під такі монотонні задачі заточений, але дивився огляди на YouTube, і відгуки по ньому поки що так собі
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥10👨💻1
https://vchasno.group/we-are-hiring-1-2/vacancy-1-4
Please open Telegram to view this post
VIEW IN TELEGRAM
❤18
Telegram
Стендап Сьогодні
Протоколи розумного будинку: Wi-Fi
#РозумнийБудинок
Почнемо мінісерію. Я багато чого тут вивчаю вперше, тож якщо у вас краща інформація — виправляйте! :) Мені, головне, для себе хочеться розуміти, в чому різниця. Бо різниця абсолютно є, і не тільки в назві.…
#РозумнийБудинок
Почнемо мінісерію. Я багато чого тут вивчаю вперше, тож якщо у вас краща інформація — виправляйте! :) Мені, головне, для себе хочеться розуміти, в чому різниця. Бо різниця абсолютно є, і не тільки в назві.…
https://t.me/stendap_sogodni/1166
Пару тижнів тому мій китайський робот пилосос щось почав сильно тупити. В мене вже раз таке було і мені помагало скинути його до заводських налаштувань. Тому я пішов і зробив ресет і цього разу. Почав з нуля підключати його до вайфаю, а він не хоче і не дуже ясно чому. Покопався трохи по редіту і найшов, що це може бути через частоту вайфая. Пилососу треба, щоб була частота 2.4 Гц, а сучасні вайфаї з заводу зазвичай налаштовані на 5 Гц.
Поліз я в налаштування роутера і бачу що стоїть якийсь смарт режим який підтримує і 2.4 Гц, і 5 Гц. Я такий «Ага!» і згадав, що минулий раз спеціально знижував частоту до 2.4 Гц, щоб підключити пилосос до вайфаю, а потім повертав у цей смарт режим назад що інтернет був нормальний. Ну все, залишилося зробити ті самі присідання і буде в мого китайськогошпигуна пилососа доступ до інтернету. Але, поки колупався в носі, побачив на цій сторінці нижче якісь налаштування мережі для IoT. Стало цікаво що звір, почав розбиратися і мені прийшло просвітлення, що це те що мені якраз й треба. Це окрема вайфай мережа зі своїм SSID і паролем, підтримує тільки 2.4 Гц і ще якісь там налаштування безпеки.
Включив цю мережу, дві хвилини діла і мій робот пилосос вже в інтернеті в своїй окремій мережі. Я не те щоб сильно переймався питаннями безпеки з IoT девайсами в локальній мережі, але подумав що вийшло гарно, що робот тепер в окремій мережі працює і нікому не заважає
Пару тижнів тому мій китайський робот пилосос щось почав сильно тупити. В мене вже раз таке було і мені помагало скинути його до заводських налаштувань. Тому я пішов і зробив ресет і цього разу. Почав з нуля підключати його до вайфаю, а він не хоче і не дуже ясно чому. Покопався трохи по редіту і найшов, що це може бути через частоту вайфая. Пилососу треба, щоб була частота 2.4 Гц, а сучасні вайфаї з заводу зазвичай налаштовані на 5 Гц.
Поліз я в налаштування роутера і бачу що стоїть якийсь смарт режим який підтримує і 2.4 Гц, і 5 Гц. Я такий «Ага!» і згадав, що минулий раз спеціально знижував частоту до 2.4 Гц, щоб підключити пилосос до вайфаю, а потім повертав у цей смарт режим назад що інтернет був нормальний. Ну все, залишилося зробити ті самі присідання і буде в мого китайського
Включив цю мережу, дві хвилини діла і мій робот пилосос вже в інтернеті в своїй окремій мережі. Я не те щоб сильно переймався питаннями безпеки з IoT девайсами в локальній мережі, але подумав що вийшло гарно, що робот тепер в окремій мережі працює і нікому не заважає
🔥16
vary: origin
Вчора розбирався з CORS і відкрив для себе HTTP-заголовок відповіді Vary:
Коли сервер повертає цей Vary з переліком заголовків, то саме ці заголовки мають братися до уваги коли кешується запит. Наприклад, робимо кудись запит з Accept-Language: uk, повертається локалізована відповідь українською і з заголовком Vary: Accept-Language. Браузер вирішує, що запит треба закешувати і коли кешує, то додає Accept-Language: uk до ключа, бо його про це вічливо попопросив сервер. Якщо зробити наступний запит вже з іншим заголовком Accept-Language: en, то браузер бачить що заголовок відрізняється і тому цей запит має оминути кеш.
Окрім самого браузера запити ще можуть же кешувати CDN, Cloudflare, Nginx, ваш сервер і вони теж хочуть знати, які заголовки треба враховувати при кешування. По дефолту до уваги береться тільки метод + URL, щоб сформувати ключ для кешування.
😐 До чого ж тут CORS? Якщо зробити один і то й же cross-origin запит з різних доменів, то вийде так, що метод і URL будуть однакові, на заголовки ж нам байдуже — знач можна кешувати! Але справа якраз в тому, що CORS заголовки у відповіді часто залежать саме від того з якого домену прилетів запит (Origin заголовок). В кінці кінців нам щоб дозволити CORS запит треба повернути значення з заголовку Origin у заголовку Access-Control-Allow-Origin
Тому якщо на шляху запиту хтось поверне закешовану відповідь для різних Origin, то вийде, що ми перший запит пропустимо, а другий ні. Окрім того це ще може мати наслідки по безпеці.
Тут якраз і вступає в силу Vary заголовок. Для CORS його рекомендують ставити так:
Тобто Origin заголовок має враховуватися при кешуванні, саме так як на і треба👍
Вчора розбирався з CORS і відкрив для себе HTTP-заголовок відповіді Vary:
Vary: *
Vary: <header-name>, …, <header-nameN>
Коли сервер повертає цей Vary з переліком заголовків, то саме ці заголовки мають братися до уваги коли кешується запит. Наприклад, робимо кудись запит з Accept-Language: uk, повертається локалізована відповідь українською і з заголовком Vary: Accept-Language. Браузер вирішує, що запит треба закешувати і коли кешує, то додає Accept-Language: uk до ключа, бо його про це вічливо попопросив сервер. Якщо зробити наступний запит вже з іншим заголовком Accept-Language: en, то браузер бачить що заголовок відрізняється і тому цей запит має оминути кеш.
Окрім самого браузера запити ще можуть же кешувати CDN, Cloudflare, Nginx, ваш сервер і вони теж хочуть знати, які заголовки треба враховувати при кешування. По дефолту до уваги береться тільки метод + URL, щоб сформувати ключ для кешування.
Access-Control-Allow-Origin: <origin>
Тому якщо на шляху запиту хтось поверне закешовану відповідь для різних Origin, то вийде, що ми перший запит пропустимо, а другий ні. Окрім того це ще може мати наслідки по безпеці.
Тут якраз і вступає в силу Vary заголовок. Для CORS його рекомендують ставити так:
Vary: Origin
Тобто Origin заголовок має враховуватися при кешуванні, саме так як на і треба
Please open Telegram to view this post
VIEW IN TELEGRAM
❤15🔥5
Євгеній Гизила
vary: origin Вчора розбирався з CORS і відкрив для себе HTTP-заголовок відповіді Vary: Vary: * Vary: <header-name>, …, <header-nameN> Коли сервер повертає цей Vary з переліком заголовків, то саме ці заголовки мають братися до уваги коли кешується запит.…
А ще на закуску гарна стаття про вразливості повʼязані з неправильними налаштуваннями CORS 🤌 https://portswigger.net/research/exploiting-cors-misconfigurations-for-bitcoins-and-bounties
Please open Telegram to view this post
VIEW IN TELEGRAM
PortSwigger Research
Exploiting CORS misconfigurations for Bitcoins and bounties
(or CORS misconfiguration misconceptions) In this post, I'll show how to identify and exploit misconfigured CORS. This is a greatly condensed version of my AppSec USA talk. If you have time (or strugg
🔥8
%PDF
На роботі розбирався з тим, яка різниця між версіями PDF, і гріх не поділитися тут. Всі версії PDF перелічувати немає сенсу, тому мій субʼєктивний рейтинг за важливістю:
1.4. Цю версію Adobe випустила в 2001 році. У неї додали прозорість для картинок, можливість вбудувати метадані і якесь там нове стиснення. Це все стало в основу формату PDF/A для тривалого зберігання, і через це ця версія досі залишається мега популярною. У цій версії базово є все, що треба звичайній людині від PDF.
1.7. У 2006 році вийшла фінальна версія PDF від Adobe. Після цього Adobe передала стандартизацію до ISO (International Organization for Standardization). ISO, у свою чергу, взяли цей же стандарт від Adobe і в 2008 опублікували його під номером ISO 32000-1. Тобто PDF 1.7 — це технічно одночасно і остання версія стандарту від Adobe, і перша версія від ISO. Оскільки ця версія більше 10 років була найостаннішою версією PDF, то для неї було написано понад пʼять тонн рядків коду. Ця версія — це безпрограшний варіант, якщо треба високу сумісність і найбільше можливостей.
2.0. Наступним кроком десь в кабінетах ISO сіли і вирішили обдумати PDF стандарт: десь спростити, десь уточнити, а десь викинути старі фічі. На додачу, вирішили додати купу нових можливостей, які мені вже важко переварити. У результаті в 2017 році вийшла покращена версія стандарту PDF під номером 2.0. Почитав в інтернеті, що люди про це говорять і всі зірки вказують на те, що за PDF 2.0 майбутнє. Але цьому майбутньому ще треба час щоб настоятися і щоб всюди додали підтримку нового стандарту.
Джерела:
1.Мені кума прислала
2.Trust me bro
3.зуб даю
На роботі розбирався з тим, яка різниця між версіями PDF, і гріх не поділитися тут. Всі версії PDF перелічувати немає сенсу, тому мій субʼєктивний рейтинг за важливістю:
1.4. Цю версію Adobe випустила в 2001 році. У неї додали прозорість для картинок, можливість вбудувати метадані і якесь там нове стиснення. Це все стало в основу формату PDF/A для тривалого зберігання, і через це ця версія досі залишається мега популярною. У цій версії базово є все, що треба звичайній людині від PDF.
1.7. У 2006 році вийшла фінальна версія PDF від Adobe. Після цього Adobe передала стандартизацію до ISO (International Organization for Standardization). ISO, у свою чергу, взяли цей же стандарт від Adobe і в 2008 опублікували його під номером ISO 32000-1. Тобто PDF 1.7 — це технічно одночасно і остання версія стандарту від Adobe, і перша версія від ISO. Оскільки ця версія більше 10 років була найостаннішою версією PDF, то для неї було написано понад пʼять тонн рядків коду. Ця версія — це безпрограшний варіант, якщо треба високу сумісність і найбільше можливостей.
2.0. Наступним кроком десь в кабінетах ISO сіли і вирішили обдумати PDF стандарт: десь спростити, десь уточнити, а десь викинути старі фічі. На додачу, вирішили додати купу нових можливостей, які мені вже важко переварити. У результаті в 2017 році вийшла покращена версія стандарту PDF під номером 2.0. Почитав в інтернеті, що люди про це говорять і всі зірки вказують на те, що за PDF 2.0 майбутнє. Але цьому майбутньому ще треба час щоб настоятися і щоб всюди додали підтримку нового стандарту.
Джерела:
1.
2.
3.
🔥22👨💻1
Євгеній Гизила
%PDF На роботі розбирався з тим, яка різниця між версіями PDF, і гріх не поділитися тут. Всі версії PDF перелічувати немає сенсу, тому мій субʼєктивний рейтинг за важливістю: 1.4. Цю версію Adobe випустила в 2001 році. У неї додали прозорість для картинок…
WTF is PDF/A?
— питання від @cpplastic
Ідея така, це звичний PDF, тільки на нього накладаються спеціальні обмеженнями, щоб його можна було відкрити умовно через 100 років і все відображалося як і раніше.
Літера в назві стандрату A це про архівування і тривале зберігання. Щоб PDF відповідав PDF/A стандарту, то фінальна PDF повинна мати вбудований шрифт, без відео, аудіо, JS, ніяких шифрувань і паролей, зовніших посилань і т.д. Тобто PDF/A стандарт не додає додаткових можливостей в стандарт PDF, лише визначає строгі правила, що може бути, а що ні в фінальній PDF. Дуже актуально для держустанов, корпорацій, бібліотек.
❤10🤩2👨💻1
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
vit bashy in Ураження сіпласпластиком
все не знав де поділитись
ви помітили як криво почав працювати пошук у ios?
пошук додатків за назвою веде у налаштування цих додатків
а про пошук налаштуванням можна просто забути
спробуйте пошукати “camera” у наташтуваннях
не знайдете
ви помітили як криво почав працювати пошук у ios?
пошук додатків за назвою веде у налаштування цих додатків
а про пошук налаштуванням можна просто забути
спробуйте пошукати “camera” у наташтуваннях
не знайдете
❤2
sslmode=prefer
Читаю про те як налаштувати з пітона до постгреса через SSL. Якщо взяти популярний psycopg, то вони посилаються на документацію libpq, яка використовується під капотом. А в документації libpq кажуть, що треба використовувати параметр sslmode. Є шість різних варіантів, які приймає цей параметр: disable, allow, prefer, require, verify-ca, verify-full. Все в цілому ОК, але дефолтне значення це ще та знахідка 🚩
З таблиці:
Як я зрозумів, якщо сервер підтримує SSL, то за замовчуванням libpq буде пробувати робити SSL підключення, шифрувати трафік, але толку з того буде мало, бо ніхто не перевіряє чи ми до справжнього серверу підключилися чи ні. Якесь це дефолтне значення на лоха, і землю гріє, але ніфіга не діє. Ще й на додачу в клаудах постгреси за замовчуванням мають включену підтримку SSL, тому libpq точно буде пробувати підключатися по SSL😮
Читаю про те як налаштувати з пітона до постгреса через SSL. Якщо взяти популярний psycopg, то вони посилаються на документацію libpq, яка використовується під капотом. А в документації libpq кажуть, що треба використовувати параметр sslmode. Є шість різних варіантів, які приймає цей параметр: disable, allow, prefer, require, verify-ca, verify-full. Все в цілому ОК, але дефолтне значення це ще та знахідка 🚩
The default value for sslmode is prefer. As is shown in the table [абзац нижче], this makes no sense from a security point of view, and it only promises performance overhead if possible. It is only provided as the default for backward compatibility, and is not recommended in secure deployments.
З таблиці:
prefer: I don't care about encryption, but I wish to pay the overhead of encryption if the server supports it
Як я зрозумів, якщо сервер підтримує SSL, то за замовчуванням libpq буде пробувати робити SSL підключення, шифрувати трафік, але толку з того буде мало, бо ніхто не перевіряє чи ми до справжнього серверу підключилися чи ні. Якесь це дефолтне значення на лоха, і землю гріє, але ніфіга не діє. Ще й на додачу в клаудах постгреси за замовчуванням мають включену підтримку SSL, тому libpq точно буде пробувати підключатися по SSL
Please open Telegram to view this post
VIEW IN TELEGRAM
🤯8😱3❤2🤩1
github .diff
Відкрив для себе, що якщо на github дописати .diff в кінці лінки на пулл реквест, то видасть прям сирий diff файл, без інерфейсу
беру жмакаю ⌘+A, потом ⌘+C, перехожу в жіпіті, роблю ⌘+V і виходить жир🤟
Відкрив для себе, що якщо на github дописати .diff в кінці лінки на пулл реквест, то видасть прям сирий diff файл, без інерфейсу
беру жмакаю ⌘+A, потом ⌘+C, перехожу в жіпіті, роблю ⌘+V і виходить жир
Please open Telegram to view this post
VIEW IN TELEGRAM
😱4🥰1👨💻1
Новий тайпчекер для пайтона, на цей раз вже від Meta
https://engineering.fb.com/2025/05/15/developer-tools/introducing-pyrefly-a-new-type-checker-and-ide-experience-for-python/
https://engineering.fb.com/2025/05/15/developer-tools/introducing-pyrefly-a-new-type-checker-and-ide-experience-for-python/
Engineering at Meta
Introducing Pyrefly: A new type checker and IDE experience for Python
Today we are announcing an alpha version of Pyrefly, an open source Python type checker and IDE extension crafted in Rust. Pyrefly is a static type checker that analyzes Python code to ensure type …
1👨💻4🎉2
schema vs scheme
Я все своє життя вважав, що між словом schema і scheme нема ніякої різниці, і це черговий прикол з American vs. British English. Кодив SweetPad і задумався погуглити, а може все таки є різниця? Бо в Xcode проєктах це слово ну дуууже часто зустрічається.
Зі словом schemA наче все просто — це для опису структури або моделі даних. Тому й JSON schema, database schema і GraphQL schema, бо вони всі про те як виглядають дані. Найчастіше зустрічається тільки в ІТ і ще десь у психології (я не перевіряв)
Інше ж слово schemE означає або план дій, або набір правил по яких щось працює: auth scheme, file-naming scheme, color scheme, cryptographic scheme, URL scheme. За межами ІТ це слово теж доволі часто використовується: ponzi scheme, pension scheme. Якщо сильно захотіти, то можна навіть умудритися перекласти це слово як “схематоз”😎
Як тоді ж правильно буде у Xcode проєктах? Там якраз схема це про те як проєкт буде збиратися, тому правильно буде scheme і в множині schemes. Хоча, як на мене, світ не розвалиться, якщо цього не знати і використати неправильне слово🤟
Я все своє життя вважав, що між словом schema і scheme нема ніякої різниці, і це черговий прикол з American vs. British English. Кодив SweetPad і задумався погуглити, а може все таки є різниця? Бо в Xcode проєктах це слово ну дуууже часто зустрічається.
Зі словом schemA наче все просто — це для опису структури або моделі даних. Тому й JSON schema, database schema і GraphQL schema, бо вони всі про те як виглядають дані. Найчастіше зустрічається тільки в ІТ і ще десь у психології (я не перевіряв)
Інше ж слово schemE означає або план дій, або набір правил по яких щось працює: auth scheme, file-naming scheme, color scheme, cryptographic scheme, URL scheme. За межами ІТ це слово теж доволі часто використовується: ponzi scheme, pension scheme. Якщо сильно захотіти, то можна навіть умудритися перекласти це слово як “схематоз”
Як тоді ж правильно буде у Xcode проєктах? Там якраз схема це про те як проєкт буде збиратися, тому правильно буде scheme і в множині schemes. Хоча, як на мене, світ не розвалиться, якщо цього не знати і використати неправильне слово
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥19👨💻2
Pro Git
Дочитав книжку “Pro Git”, Scott Chacon, Ben Straub. Мене підкупило, що вона є в EPUB форматі та ще й безплатна.
Основна частина книги — це власне про те як користуватися гіт: як комітити, як мерджити і ребейзити, як робити гілки і як робити відновлення. Ця частина мені легко зайшла, але з неї я не багато нового дізнався.
Найбільше мені сподобалася частина книги, в якій пояснюється внутрощі git, як зберігаються файли, що таке index і working tree, як git реалізовує теги, гілки, посилання. В цьому розділі автор визначає git взагалі як файлову систему і пояснює поступово чому так і що це значить:
Як бонус, для мене було відкриттям, що в базу git можна просто взяти і записати довільні дані, без жодного файлу, коміта чи гілки. Ось попробуйте найти секретний текст, який я заховав у цьому git-репо git-is-cool. Хто найде тому скину книжку в особисті😂
Дочитав книжку “Pro Git”, Scott Chacon, Ben Straub. Мене підкупило, що вона є в EPUB форматі та ще й безплатна.
Основна частина книги — це власне про те як користуватися гіт: як комітити, як мерджити і ребейзити, як робити гілки і як робити відновлення. Ця частина мені легко зайшла, але з неї я не багато нового дізнався.
Найбільше мені сподобалася частина книги, в якій пояснюється внутрощі git, як зберігаються файли, що таке index і working tree, як git реалізовує теги, гілки, посилання. В цьому розділі автор визначає git взагалі як файлову систему і пояснює поступово чому так і що це значить:
Git is fundamentally a content-addressable filesystem with a VCS user interface written on top of it.
Як бонус, для мене було відкриттям, що в базу git можна просто взяти і записати довільні дані, без жодного файлу, коміта чи гілки. Ось попробуйте найти секретний текст, який я заховав у цьому git-репо git-is-cool. Хто найде тому скину книжку в особисті
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥8❤2🥰2
Євгеній Гизила
github .diff Відкрив для себе, що якщо на github дописати .diff в кінці лінки на пулл реквест, то видасть прям сирий diff файл, без інерфейсу беру жмакаю ⌘+A, потом ⌘+C, перехожу в жіпіті, роблю ⌘+V і виходить жир 🤟
В копілку до само-ревʼю коду чатом-гпт, я нещодавно для себе відкрив параметр --function-context в git. Ідея цього параметру така, що замість того щоб показувати три рядки до і три після зміни, git буде старатися найти межі функції чи класу і захопити їх з собою у відповідь git diff. Для ШІ цей контекст дуже корисний, тому відповідно виходять набагато кращі ревʼю від нього
git diff --function-context | pbcopy
🔥39
distro пакет
Вчора ввечері прибирався по дому і ходив слухав якесь відео, де автор жаліється, що куди не глянь, хоч на rust, хоч на js, але щоб зробити невеликий веб сервіс треба скачати мільйон залежностей з інтернету. А потім з цими залежностями якось треба жити, їх оновлювати, слідкувати за вразливостями. Або не дай боже залишити проєкт на рік десь в шухлядці, то його після скільки часу вже ніхто не зможе зібрати.
Чомусь запамʼятався цей момент. Я задумався, чому немає якихось великих жирних пакетів «все-для-всіх» чи «все-для-вебу», які є просто збіркою з інших завендорених проєктів. Так, щоб покрило основу кількість потреб (наприклад, для вебу), випускалося раз на рік, оновлювалося як один пакет і мало план міграцій між версіями.
Фантазую: береться fastapi, sqlalchemy, pytest, десяток інших ліб, далі клонуються всі в один проєкт і публікуються як один пакет, нехай під назвою std_web:
Такий собі міні-дистрибутив, типу debian, тільки не лінукса, а бібліотек для якось мови і сфери розробки⌨️
Вчора ввечері прибирався по дому і ходив слухав якесь відео, де автор жаліється, що куди не глянь, хоч на rust, хоч на js, але щоб зробити невеликий веб сервіс треба скачати мільйон залежностей з інтернету. А потім з цими залежностями якось треба жити, їх оновлювати, слідкувати за вразливостями. Або не дай боже залишити проєкт на рік десь в шухлядці, то його після скільки часу вже ніхто не зможе зібрати.
Чомусь запамʼятався цей момент. Я задумався, чому немає якихось великих жирних пакетів «все-для-всіх» чи «все-для-вебу», які є просто збіркою з інших завендорених проєктів. Так, щоб покрило основу кількість потреб (наприклад, для вебу), випускалося раз на рік, оновлювалося як один пакет і мало план міграцій між версіями.
Фантазую: береться fastapi, sqlalchemy, pytest, десяток інших ліб, далі клонуються всі в один проєкт і публікуються як один пакет, нехай під назвою std_web:
from std_web.fastapi import FastAPI
from std_web.pydantic import BaseModel
Такий собі міні-дистрибутив, типу debian, тільки не лінукса, а бібліотек для якось мови і сфери розробки
Please open Telegram to view this post
VIEW IN TELEGRAM
❤10😱2